Activities


Overview

Activity modeling emphasizes the sequence and conditions for coordinating lower-level behaviors, rather than which  classifiers own those behaviors. These are commonly called control flow and object flow models. The actions coordinated by activity models can be initiated because other actions finish executing, because objects and data become available, or because events occur external to the flow.

Actions and activities

An action execution corresponds to the execution of a particular action within an activity. Similarly, an activity execution is the execution of an activity, ultimately including the executions of actions within it. Each action in an activity may execute zero, one, or more times for each activity execution. Execution is not instantaneous, but takes place over a period of time.

The UML does not provide for the specification of a time metric, but only describes sequences of executions. Activities and other groupings of actions must be executed in a number of steps, including control of the execution of nested actions.

At the minimum, actions need access to data, they need to transform and test data, and actions may require sequencing. The activities specification (at the higher compliance levels) allows for several (logical) threads of control executing at once and synchronization mechanisms to ensure that activities execute in a specified order. Semantics based on concurrent execution can then be mapped easily into a distributed implementation. However, the fact that the UML allows for concurrently executing objects does not necessarily imply a distributed software structure. Some implementations may group together objects into a single task and execute sequentially--so long as the behavior of the implementation conforms to the sequencing constraints of the specification.

There are potentially many ways of implementing the same specification, and any implementation that preserves the information content and behavior of the specification is acceptable. Because the implementation can have a different structure from that of the specification, there is a mapping between the specification and its implementation. This mapping need not be one-to-one: an implementation need not even use object-orientation, or it might choose a different set of classes from the original specification.

The mapping may be carried out by hand by overlaying physical models of computers and tasks for implementation purposes, or the mapping could be carried out automatically. This specification neither provides the overlays, nor does it provide for code generation explicitly, but the specification makes both approaches possible.

See the "Activity" and "Action" metaclasses for more introduction and semantic framework.

BasicActivities

The basic level supports modeling of traditional sequential flow charts. It includes control sequencing, but explicit forks and joins of control are not supported at this level. Decisions and merges are supported at this level and need not be well structured.

IntermediateActivities

The intermediate level supports modeling of activity diagrams that include concurrent control and data flow. It supports modeling similar to traditional Petri nets with queuing. It requires the basic level.

The intermediate and structured levels are orthogonal. Either can be used without the other or both can be used to support modeling that includes both concurrency and structured control constructs.

CompleteActivities

The complete level adds constructs that enhance the lower level models, such as edge weights and streaming.

StructuredActivities

The structured level supports modeling of traditional structured programming constructs, such as loops and conditionals, as an addition the basic nonstructured activity sequencing. It requires the basic level. It is compatible with the intermediate and complete levels.

CompleteStructuredActivities

This level adds support for data flow output pins of conditionals and loops. It is intended to be used in conjunction with the intermediate layer, which supports explicit concurrency, but there is no actual dependency between the levels.

ExtraStructuredActivities

The extra structure level supports exception handling as found in traditional programming languages and invocation of behaviors on sets of values. It requires the structured level.