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.