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.