Common Behaviors
Overview
The Common Behaviors packages specify the core concepts required for
dynamic elements and provides the infrastructure to support more
detailed definitions of behavior. Figure 306 shows a domain model
explaining the relationship between occurrences of behaviors.
Note The models shown in Figure 306 through Figure 310 are not metamodels but show objects in
the semantic domain and relationships between these objects. These
models are used to give an informal explication of the dynamic
semantics of the classes of the UML metamodel.
Any behavior is the direct consequence of the action of at least one
object. A behavior describes how the states of these objects, as
reflected by their structural features, change over time. Behaviors, as
such, do not exist on their own, and they do not communicate. If a
behavior operates on data, that data is obtained from the host object.
(Note that an executing behavior may itself be an object, however.)
There are two kinds of behaviors, emergent behavior and executing
behavior. An executing behavior is performed by an object (its
host) and is the description of the behavior of this object. An
executing behavior is directly caused by the invocation of a behavioral
feature of that object or by its creation. In either case, it is a
consequence of the execution of an action by some related object. A
behavior has access to the structural features of its host object.
Objects that may host
behaviors are specified by the concrete subtypes of the BehavioredClassifier
metaclass.
Emergent behavior results from the interaction of one or more
participant objects. If the participating objects are parts of a larger
composite object, an emerging behavior can be seen as indirectly
describing the behavior of the container object also. Nevertheless, an
emergent behavior is simply the sum of the executing behaviors of the
participant objects.Occurring behaviors are specified by the concrete
subtypes of the abstract Behavior metaclass. Behavior
specifications
can be used to define the behavior of an object, or they can be used to
describe or illustrate the behavior of an object. The latter may only
focus on a relevant subset of the behavior an object may exhibit
(allowed behavior), or it may focus on behavior an object must not
exhibit (forbidden behavior).
Albeit behavior is ultimately related to an object, emergent behavior
may also be specified for non-instantiable classifiers, such as
interfaces or collaborations. Such behaviors describe the interaction
of the objects that realize the interfaces or the parts of the
collaboration (see
"Collaboration (from Collaborations)" ).
BasicBehaviors
The BasicBehaviors subpackage of the Common Behavior package introduces
the framework that will be used to specify behaviors. The concrete
subtypes of Behavior will provide different mechanisms to specify
behaviors. A variety of specification mechanisms are supported by
the UML, such as automata ("StateMachine
(from BehaviorStatemachines)" ), Petri-net like
graphs ("Activity
(from BasicBehaviors)" ), informal descriptions ("UseCase (from UseCases)"),
or partially-ordered sequences of events
("Interaction
(from BasicInteraction, Fragments)" ).
Profiles may introduce additional styles of behavioral specification.
The styles of behavioral specification differ in their expressive
power and domain of applicability. Further, they may specify behaviors
either
explicitly, by describing the observable events resulting from the
occurrence of the behavior, or implicitly, by describing a machine that
would induce these events. The relationship between a specified
behavior and its hosting or participating instances is independent of
the specification mechanism chosen and described in the common behavior
package. The choice of specification mechanism is one of convenience
and purpose; typically, the same kind of behavior could be described by
any of the different mechanisms. Note that not all behaviors can be
described by each of the different specification mechanisms, as these
do not all have the same expressive power. However, for many behaviors,
the choice of specification mechanism is one of convenience.
As shown in the domain model of Figure 307, the execution of a behavior
may be caused by a call behavior event (representing the direct
invocation of a behavior through an action) or a trigger event
(representing an indirect invocation of a behavior, such as through an
operation call). A start event marks the beginning of a behavior
execution, while its completion is accompanied by a termination event.

Communications
The Communications subpackage of the Common Behavior package adds
the infrastructure to communicate between objects in the system and to
invoke behaviors. The domain model shown in Figure 308 explains how
communication takes place. Note that this domain model specifies the
semantics of communication between objects in a system. Not all aspects
of the domain model are explicitly represented in the specification of
the system but may be implied by the dynamic semantics of the
constructs used in a specification.
An action representing the invocation of a behavioral feature is
executed by a sender object resulting in an invocation event occurring.
The invocation event may represent the sending of a signal or the call
to an operation. As a result of the invocation event, a request is
generated. A request is an object capturing the data that was passed to
the action causing the invocation event (the arguments which must match
the parameters of the invoked behavioral feature), information about
the nature of the request (i.e., the behavioral feature that was
invoked), the identities of the sender and receiver objects, as well as
sufficient information about the behavior execution to enable the
return of a reply from the invoked behavior, where appropriate. (In
profiles, the request object may include additional information, for
example, a time stamp.) While each request is targeted at exactly one
receiver object and caused by exactly one sending object, an invocation
event may result in a number of requests being generated (as in a
signal broadcast). The receiver may be the same object that is the
sender, it may be local (i.e., an object held in a slot of the
currently executing object, or the currently executing object itself,
or the object owning the currently executing object), or it may be
remote. The manner of transmitting the request object, the amount of
time required to transmit it, the order in which the transmissions
reach their receiver objects, and the path for reaching the receiver
objects are undefined. Once the generated request arrives at the
receiver object, a receiving event will occur.
Several kinds of requests exist between instances, for example, sending
a signal or invoking an operation. The kind of request is determined by
the kind of invocation event that caused it, as shown in Figure 309.
The former is used to trigger a reaction in the receiver in an
asynchronous way and without a reply, while the latter applies an
operation to an instance, which may be either synchronously or
asynchronously and may require a reply from the receiver to the sender.
A send invocation event creates a send request and causes a signal
event in the receiver. A call invocation event creates a call request
and causes a call event in the receiver.
Invocation events are specified by various kinds of actions (see
Chapter 5, "Actions"). A send request is specified by a Signal (see "Signal"). A call request is
derived from the operation associated with the specification of the
call invocation event. Signal events and call events are specified by
the corresponding metaclasses (see "SignalTrigger" and "CallTrigger").
As shown in Figure 308, the invocation event that
eventually will lead to a behavior invocation which itself occurs
within the context of a behavior execution, is in turn hosted by an
object. In case of an operation invocation, the invoked behavior will
be able to reply to the action in virtue of having knowledge of this
behavior execution.
eceiving events may cause a behavioral response. For example, a
statemachine may transition to a new state upon detection of a trigger
event or an activity may be enabled upon detection of a receiving
event. The specific mechanism by which the data passed with the request
(the attributes of the request object) are made available as arguments
to the invoked behavior (e.g., whether the data or copies are passed
with the request) is a semantic variation point. The behavior
will be executed in the context of the receiving object (i.e., the
receiving object will host the behavior execution). The details of
identifying the behavior to be invoked in response to the occurrence of
an event is a semantic variation point. The occurrence of spontaneous
events may also trigger behaviors: The occurrence of a change event
(see "ChangeTrigger") is
based on some expression becoming true. A time event occurs
when a predetermined deadline expires (see "TimeTrigger" ). No data is
passed by the
occurrence of a spontaneous event. Figure 310 shows the hierarchy of
such trigger events. The occurrence of trigger events, may also cause
the invocation of a behavior in the context of the containing object.
When a trigger event is recognized by an object, it may have an
immediate effect or the event may be saved in an event pool and have a
later effect when it is matched by a trigger specified for a behavior.
SimpleTime
The SimpleTime subpackage of the Common Behavior package adds
metaclasses to represent time and durations, as well as actions to
observe the passing of time.
The simple model of time described here is intended as an approximation
for situations where the more complex aspects of time and time
measurement can safely be ignored. For example, this model does not
account for the relativistic effects that occur in many distributed
systems, or the effects resulting from imperfect clocks with finite
resolution, overflows, drift, skew, etc. It is assumed that
applications for which such characteristics are relevant will use a
more sophisticated model of time provided by an appropriate profile.