| Previous | UML Classes | Table of Contents | UML Packages | Next |
The Common Behaviors packages specify the core concepts required for dynamic elements and provides the infrastructure to support
more detailed definitions of behavior.
Figure 13.1
shows a domain model explaining the relationship between occurrences of behaviors.
Note – The models shown in
Figure 13.1
through Figu
re 13.4
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.
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 can result from 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 ) on
page 175).
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
sp
ecification mechanisms are supported by the UML, such as automata (
StateMachine (from BehaviorStateMachines )
on page 586), Petri-net like graphs (Activity (from BasicActivities , Comp
leteActivities, FundamentalActivities ,
StructuredActivities) on page 328
), informal descriptions (
UseCase (from UseCases ) on
page 620), or partially-ordered sequences of event occurrences (
Interaction (from BasicInteraction, Fr
agments) on page 501). 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 event occurrences resulting from the execution 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 13.2
, the execution of a behavior may be caused by a call behavior occurrence (representing the direct invocation of a behavior
through an action) or a trigger occurrence (representing an indirect invocation of a behavior, such as through an operation
call). A start occurrence marks the beginning of a behavior execution, while its completion is accompanied by a termination
occurrence.
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 13.3
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 that 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 occurrence of 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.
Issue 8292 -fix minor typos
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 occurrence that caused it, as shown in
Figure 13.4
. 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 synchronous or asynchronous and may require a reply from the receiver to
the sender. A send invocation occurrence creates a send request and causes a signal occurrence in the receiver. A call invocation
occurrence creates a call request and causes a call occurrence in the receiver.
Issue 8292 -remove ‘event’; replace ‘call’ with ‘signal’
An invocation occurrence represents the recognition of an invocation request after its receipt by a target object. Invocation
event occurrences are the result of the execution of invocation actions (see
InvocationAction (from BasicActions ) on
pag
e 267
). Invocation actions include send actions and call actions. A send action is specified by a Signal (see
Signal (from
Communications ) on
page 467) and argument values. The execution of a send action results in a send request, which results in a signal event occurrence
when it is recognized by the target object. A call action is specified by an Operation and argument values. The execution
of a call action results in a call request, which results in a call event occurrence when it is recognized by the target object.
Signal event occurrences and call event occurrences are specified by the corresponding metaclasses (see
SignalEvent (from Communications ) on page 468
and
CallEvent (from Communications ) on
page 453).
As shown in Figu
re 13.3
, an object hosts a behavior execution (i.e., a behavior will be executed in the context of that object). The execution of
an invocation action by the behavior constitutes an invocation occurrence. The invocation occurrence results in a request
object that transmits the invocation request from the sender object (caller) to the receiver object (target). The receipt
of the request by the receiver is manifest as a receive occurrence. When the receive occurrence matches a trigger defined
in the class of the target object, it causes the execution of a behavior. The details of identifying the behavior to be invoked
in response to the occurrence of an event are a semantic variation point. The resulting behavior execution is hosted by the
target object. 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. If the invocation action is synchronous, the request object also includes sufficient information to identify
the execution that invoked the behavior, but this information is not available for the use of the invoked behavior (and, therefore,
is not modeled). When a synchronous execution completes, this information is used to direct a reply message to the original
behavior execution.
The detection of an (event) occurrence by an object may cause a behavioral response. For example, a state machine may transition
to a new state upon the detection of the occurrence of an event specified by a trigger owned by the state machine, or an activity
may be enabled upon the receipt of a message. When an event occurrence 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.
The occurrence of a change event (see
ChangeEvent (from Communications ) on page 454) is based on some expression
becoming true. A time event occurs when a predetermined deadline expires (see TimeEvent (from Communications ,
SimpleTime ) on page 470). No data is passed by the occurrence of a change event or a time event. Figure 13.12 shows the
hierarchy of events.
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.