Actions
Overview
Basic Concepts
The abstract concept of an action is found in the Activities
chapter. This chapter covers its specific actions.
An action is the fundamental unit of behavior specification. An action
takes a set of inputs and converts them into a set of outputs, though
either or both sets may be empty. In addition, some actions modify the
state of the system in which the action executes. The values that are
the inputs to an action may be obtained from the results of other
actions using the activity flow model, or they may be described by
value specifications. The outputs of the action may be provided as
inputs to other actions using the activity flow model.
Actions are contained in activities, which provide their context.
Activities provide control and data sequencing constraints among
actions as well as nested structuring mechanisms for control and scope.
See the Activities chapter for details. The Actions chapter is
concerned with the semantics of individual, primitive actions.
Intermediate Concepts
The intermediate level describes the various action primitives that
may be executed within UML activity models. These primitive actions are
defined in such a way as to enable the maximum range of mappings.
Specifically, primitive actions are defined so that they either carry
out a computation or access object memory, and never both. This
approach enables clean mappings to a physical model, even those with
data organizations different from that suggested by the specification.
In
addition, any re-organization of the data structure will leave the
specification of the computation unaffected.A surface action language
would encompass both primitive actions and the control mechanisms
provided by activities. In addition, a surface language may map
higher-level constructs to the actions. For example, in a composition
association where the deletion of an instance implies the deletion of
all its components, the specification defines the delete action to
remove only
the single instance, and the specification requires further deletions
for each of the component instances. A surface language could choose to
define a delete-composition operation as a single unit as a shorthand
for several deletions that cascade across other associations.
A particular surface language could implement each semantic construct
one-to-one, or it could define higher-level, composite constructs to
offer the modeler both power and convenience. This specification, then,
expresses the fundamental semantics in terms of primitive behavioral
concepts that are conceptually simple to implement. Modelers can work
in terms of higher-level constructs as provided by their chosen surface
language or notation.
The semantic primitives are defined to enable the construction of
different execution engines, each of which may have different
performance characteristics. A model compiler builder can optimize the
structure of the software to meet specific performance requirements, so
long as the semantic behavior of the specification and the
implementation remain the same. For example, one engine might be fully
sequential within a single task, while another may separate the classes
into different
processors based on potential overlapping of processing, and yet others
may separate the classes in a client-server, or even a three-tier model
The modeler can provide "hints" to the execution engine when the
modeler has special knowledge of the domain solution that could be of
value in optimizing the execution engine. For example, instances
could--by design--be partitioned to match the distribution selected, so
tests based on this partitioning can be optimized on each processor.
The execution engines are not required to check or enforce such hints.
An execution engine can either assume that the modeler is correct, or
just ignore it. An execution engine is not required to verify that the
modeler's assertion is true.
When an action violates aspects of static UML modeling that constrain
runtime behavior, the semantics is left undefined. For example,
attempting to create an instance of an abstract class is undefined:
some languages may make this action illegal, others may create a
partial instance for testing purposes. The semantics are also left
undefined in situations that require classes as values at runtime.
However, in the execution of actions the lower multiplicity bound
ignored and no error or undefined
semantics is implied. (Otherwise it is impossible to use actions to
pass through the intermediate configurations necessary to construct
object configurations that satisfy multiplicity constraints.) The
modeler must determine when minimum multiplicity should be enforced,
and these points cannot be everywhere or the configuration cannot
change.
Invocation Actions
The actions defined in this package perform operation calls and
signal sends (including both transmissions to specific targets and
broadcasts to the available "universe"). Operations are specified in
the model and can be dynamically selected only through polymorphism.
Signals are specified by a signal object, whose type represents the
kind of message transmitted between objects, and can be dynamically
created. Note that operations may be bound to activities (procedures),
state machine transitions, or other behaviors. The receipt of signals
may be bound to activities, state machine transitions, or other
behaviors.
There is also an action to directly invoke behavior.
Read Write Actions
Objects, structural features, links, and variables have values that
are available to actions. Objects can be created and destroyed;
structural features and variables have values; links can be created and
destroyed, and can reference values through their ends; all of which
are available to actions. Read actions get values, while write actions
modify values and create and destroy objects and links. Read and write
actions share the structures for identifying the structural features,
links, and variables they access.
The use of qualifiers on associations is supported in CompleteActions.
Read actions do not modify the values they access, while write actions
have only limited effect. The semantics of actions that read and write
associations that have a static end is undefined.
Object actions create and destroy objects. Structural feature actions
support the reading and writing of structural features. The abstract
metaclass StructuralFeatureAction statically specifies the structural
feature being accessed. The object to access is specified dynamically,
by referring to an input pin on which the object will be placed at
runtime. The semantics for static features is undefined. Association
actions operate on associations and links. In the description of these
actions, the term "associations" does not include those modeled with
association classes, unless specifically indicated. Similarly, a "link"
is not a link object unless specifically indicated. The semantics of
actions that read and write associations that have a static end is
undefined. Variable actions support the reading and writing of
variables. The abstract metaclass VariableAction statically specifies
the variable being accessed. Variable actions can only access variables
within the activity of which the action is a part.
Computation Actions
Computation actions transform a set of input values to a set of
output values by invoking a function. Primitive functions represent
functions from a set of input values to a set of output values. The
execution of a primitive function depends only on the input values and
has no other effect than to compute output values. A primitive function
does not read or write structural feature or link values, nor otherwise
interact with object memory or other objects. Its behavior is
completely self-contained.
Specific primitive functions are not defined in the UML, but would be
defined in domain-specific extensions. Typical primitive functions
would include arithmetic, Boolean, and string functions.
Complete Concepts
The major constructs associated with complete actions are outlined
below.
Read Write Actions
Additional actions deal with the relation between object and class
and link objects. These read the instances of a given classifier, check
which classifier an instance is classified by, and change the
classifier of an instance. Link object actions operate on instances of
association classes. Also the reading and writing actions of
associations are extended to support qualifiers.
Other Actions
Actions are defined for raising exceptions and accepting events,
including operation calls. The StartOwnedBehaviorAction provides a way
to indicate when the behavior of a newly created object should begin to
execute.