| Previous | UML Classes | Table of Contents | UML Packages | Next |
Issue 8770 - replace third sentence
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. This chapter defines semantics for a number of specialized actions, as
described below. Some of the actions modify the state of the system in which the action executes. The values that are the
inputs to an action may be described by value specifications, obtained from the output of actions that have one output (in
StructuredActions ), or in ways specific to the behaviors that use them. For example, the activity flow model supports providing
inputs to actions from the outputs of other actions.
Actions are contained in behaviors, which provide their context. Behaviors provide constraints among actions to determine
when they execute and what inputs they have. The Actions chapter is concerned with the semantics of individual, primitive
actions.
Issue 8144 - restore ‘Operations’ instead of ‘operation calls’; other fixes
Basic actions include those that perform operation calls, signal sends, and direct behavior invocations. 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, state machine transitions, or other behaviors. The receipt of signals may be bound to activities, state machine
transitions, or other behaviors.
Issue 8144 - fix miscellaneous typos
The intermediate level describes the various primitive actions. These primitive actions are defined in such a way as to enable
the maximum range of mappings. Specifically, a primitive action either carries out a computation or accesses object memory,
but 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 behaviors. In addition,
a surface language may map higher-level constructs to the actions. For example, creating an object may involve initializing
attribute values or creating objects for mandatory associations. The specification defines the create action to only create
the object, and requires further actions to initialize attribute values and create objects for mandatory associations. A surface
language could choose to define a creation operation with initialization as a single unit as a shorthand for several actions.
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 is 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
More invocation actions are defined for broadcasting signals to the available universe and transmitting objects that are not
signals.
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.
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.
Issue 8144 -minor typos and rewording for clarification
Value specifications cover various expressions ranging from implementation-dependent constants to complex expressions,
with side-effects. An action is defined for evaluating these. Also see ValuePin (from BasicActions ) on page 301.
The major constructs associated with complete actions are outlined below.
228 UML Superstructure Specification, v2.0
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 accepting events, including operation calls, and retrieving the property values of an object all at
once. The StartClassifierBehaviorAction provides a way to indicate when the classifier behavior of a newly created object
should begin to execute.
These actions operate in the context of activities and structured nodes. 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. An action is defined for raising exceptions and a
kind of input pin is defined for accepting the output of an action without using flows.