| Previous | UML Classes | Table of Contents | UML Packages | Next |
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.
An action execution corresponds to the execution of a particular action. 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. 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 (from BasicActivities , CompleteActivities , FundamentalActivities , StructuredActivities) and Action
(from CompleteActivities , FundamentalActivities , StructuredActivities) metaclasses for more introduction and semantic
framework.
The fundamental level defines activities as containing nodes, which includes actions. This level is shared between the flow
and structured forms of activities.
This level includes control sequencing and data flow between actions, but explicit forks and joins of control, as well as
decisions and merges, are not supported. The basic and structured levels are orthogonal. Either can be used without the other
or both can be used to support modeling that includes both flows and structured control constructs.
The intermediate level supports modeling of activity diagrams that include concurrent control and data flow, and decisions.
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.
The complete level adds constructs that enhance the lower level models, such as edge weights and streaming.
Issue 8202 -replace ‘basic’ with ‘fundamental’
The structured level supports modeling of traditional structured programming constructs, such as sequences, loops, and conditionals,
as an addition to fundamental activity nodes. It requires the fundamental level. It is compatible with the intermediate and
complete levels.
This level adds support for data flow output pins of sequences, conditionals, and loops. It depends on the basic layer for
flows.
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.