UML Common Behavior
In UML specification, the common behaviors specify the core concepts required for dynamic elements and provide the infrastructure to support more detailed definitions of behavior. Elements of the common behaviors could be used when creating behavior diagrams.
Common behaviors include: behavior, behaviored classifier, event, trigger, signal, reception, interval constraint, duration constraint, time constraint.
Behavior
Behavior is a class which specifies how the classifier which owns the behavior changes its state over time. This specification may be either a definition of possible behavior execution or emergent behavior, or a selective illustration of an interesting subset of possible executions. The latter form is typically used for capturing examples, such as a trace of a particular execution.
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 do not exist on their own, and they do not communicate.
Instantiating a behavior is referred to as "invoking" the behavior, an instantiated behavior is also called a behavior "execution." When a behavior is invoked, its attributes and parameters (if any) are created and appropriately initialized.
A behavior can also be instantiated as an object, the same way as for common classes. When a behavior is instantiated as an object, it becomes its own context.
[UML 2.4.1 Specification] defines two kinds of behavior: executing behavior and emergent behavior. Note, that these two kinds of behavior are informal and are not subclasses of behavior.
Behavior has no specific notation and could be depicted as a class.
Behavior can be specialized, with specific notation and the detailed semantics defined by its subclasses. A variety of mechanisms to specify behavior are supported by the UML, such as automata for state machines, Petri-net like graphs for activities, informal descriptions for use cases, partially-ordered sequences of event occurrences for interaction. Profiles may introduce additional styles of behavioral specification.
Subclasses of behavior are:
- activity,
- state machine,
- interaction,
- opaque behavior.
UML Behaviors - Activity, State Machine, Interaction, and Opaque Behavior.
Note, that use case is a behaviored classifier, not a behavior.
Executing Behavior
An executing behavior is a kind of behavior which is performed by an object (called host) and is the description of the behavior of this object. Objects that may host behaviors are specified by the concrete subtypes of the behaviored classifier.
An executing behavior is directly caused either by the invocation of a behavioral feature of the host object or by its creation.
Behavior has access to the structural features of its host object and to parameters of the behavior, if any.
When a behavior is associated with the method of a behavioral feature, it defines the implementation of the feature.
Emergent Behavior
Emergent behavior is a kind of behavior which results from the interaction of one or more participant objects.
The participating objects could be parts of a composite object. In this case the emergent behavior indirectly describes the behavior of the composite.
Behaviored Classifier
Behaviored classifier is a classifier which can have behaviors defined in its context (namespace). One of these behaviors owned by the classifier may specify the behavior of the classifier itself.
When an instance of a behaviored classifier is created, its classifier behavior is invoked. Behavior owned by the classifier may reference features of the classifier.
When some event happens and it is recognized by an instance of behaviored classifier, it may trigger immediate invocation of behavior or this event may be saved to trigger the effect later. Whether only one or several appropriate behaviors are triggered and the ordering of the events in the input pool is not defined by UML specification.
Some examples (subclasses) of behaviored classifiers in UML are:
Behaviored classifier has no specific notation, and is notated as classifier. Subclasses of behaviored classifier could have specific notation, e.g. actors and collaborations.
Trigger
Trigger is a named element which is used to relate specific event to a behavior that may affect an instance of the classifier.
Events may cause execution of behaviors (e.g., the execution of the effect activity of a transition in a state machine). A trigger specifies the event that may trigger a behavior execution. Each trigger is associated with exactly one event.
A trigger is notated as unnamed event it is associated with. The details of the syntax for the event are defined by the different subclasses of event:
trigger ::= call-event | signal-event | any-receive-event | time-event | change-event
Signal
A signal is a classifier which specifies communication of send request instances between objects.
The receiving object handles the received request instances as specified by its receptions. The data carried by a send request (which was passed to it by the send invocation occurrence that caused that request) are represented as attributes of the signal. A signal is defined independently of the classifiers handling the signal occurrence.
A signal triggers a reaction in the receiver in an asynchronous way and without a reply. The sender of a signal will not block waiting for a reply but continue execution immediately. By declaring a reception associated to a given signal, a classifier specifies that its instances will be able to receive that signal, or a subtype thereof, and will respond to it with the designated behavior.
A signal is depicted by a classifier symbol with the keyword «signal».
The Notify Customer signal
Reception
A reception is behavioral feature declaring that a classifier is prepared to react to the receipt of a signal. A reception designates a signal and specifies the expected behavioral response. The details of handling a signal are specified by the behavior associated with the reception or the classifier itself.
The receipt of a signal instance by the instance of the classifier owning a matching reception will cause the asynchronous invocation of the behavior specified as the method of the reception. A reception matches a signal if the received signal is a subtype of the signal referenced by the reception.
The details of how the behavior responds to the received signal depend on the kind of behavior associated with the reception. (For example, if the reception is implemented by a state machine, the signal event will trigger a transition and subsequent effects as specified by that state machine.)
Reception is shown using the notation for operations with the keyword «signal».
Customer is prepared to react to the receipt of
the Notify Customer signal
Interval Constraint
Interval constraint is constraint that refers to an interval. The interval determines if the constraint is satisfied.
All traces where the constraints are violated are negative traces, i.e., if they occur in practice the system is considered as failed.
An interval constraint is shown as a graphical association between an interval and the constructs that this interval constrains. The concrete form is given in its subclasses.
Some subclasses of interval constraint are:
Duration Constraint
Duration constraint is an interval constraint that refers to a duration interval. The duration interval is duration used to determine whether the constraint is satisfied.
The semantics of a duration constraint is inherited from constraints. If constraints are violated, traces become negative which means that system is considered as failed.
Duration constraint is shown as some graphical association between a duration interval and the constructs that it constrains. The notation is specific to the diagram type. An example below shows a duration constraint notation for timing diagram.
Ice should melt into water in 1 to 6 minutes
Time Constraint
Time constraint is an interval constraint that refers to a time interval. The time interval is time expression used to determine whether the constraint is satisfied.
The semantics of a time constraint is inherited from constraints. All traces where the constraints are violated are negative traces, i.e., if they occur, the system is considered as failed.
Time constraint is shown as graphical association between a time interval and the construct that it constrains. Typically this graphical association is a small line, e.g., between an occurrence specification and a time interval. An example below shows a time constraint notation for timing diagram.
Person should wake up between 5:40 am and 6 am