Class Descriptions


Activity(from BasicBehaviors)

An activity specifies behavior by its body string.

Description

An activity contains a language-specific text string used to describe a computation, and an optional specification of the language. OCL, natural language, or programming languages may be used to specify an activity.

Attributes
Associations

No additional associations.

Constraints

No additional constraints.

Semantics

The interpretation of the activity body depends on the specified language.

Notation

See "OpaqueExpression (from Kernel)".

Changes from UML 1.x

In UML 1.4, the function of the Activity metaclass, as defined in this package, was subsumed by Expression.

 AnyTrigger (from Communications)


Description

An AnyTrigger for a given state specifies that the transition is triggered for all applicable message triggers except for those specified explicitly on other transitions for this state.

Attributes

No additional attributes.

Associations

No additional associations.

Constraints

No additional constraints.

Semantics

An AnyTrigger for a given state specifies that the transition is triggered for all applicable message triggers except for  those specified explicitly on other transitions for this state.

Notation

Any AnyTrigger is denoted by the string "all" used as the trigger.

Changes from UML 1.x

This construct has been added.

Behavior (from BasicBehaviors)

Description

Behavior is a specification of how its context classifier changes 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.

A classifier behavior is always a definition of behavior and not an illustration. It describes the sequence of state changes an instance of a classifier may undergo in the course of its lifetime. Its precise semantics depends on the kind of classifier. For example, the classifier behavior of a collaboration represents emergent behavior of all the parts, whereas the classifier behavior of a class is just the behavior of instances of the class separated from the behaviors of any of its parts.

When a behavior is associated as the method of a behavioral feature, it defines the implementation of that feature; i.e., the computation that generates the effects of the behavioral feature.

As a classifier, a behavior can be specialized. Instantiating a behavior is referred to as "invocating" the behavior, an instantiated behavior is also called a behavior "execution." A behavior may be invoked directly or its invocation may be the result of invoking the behavioral feature that specifies this behavior. A behavior can also be instantiated as an object in virtue of it being a class.

The specification of a behavior can take a number of forms, as described in the subclasses of Behavior. Behavior is an abstract metaclass factoring out the commonalities of these different specification mechanisms.

When a behavior is invoked, its execution receives a set of input values that are used to affect the course of execution and as a result of its execution it produces a set of output values which are returned, as specified by its parameters. The observable effects of a behavior execution may include changes of values of various objects involved in the execution, the creation and destruction of objects, generation of communications between objects, as well as an explicit set of output
values.

Attributes
Associations
  • specification: BehavioralFeature [ 0..1 ]
Designates a behavioral feature that the behavior implements. The behavioral feature must be owned by the classifier that owns the behavior or be inherited by it. The parameters of the behavioral feature and the implementing behavior must match. If a behavior does not have a specification, it is directly associated with a classifier (i.e., it is the behavior of the classifier as a whole).
  • context: BehavioredClassifier [ 0..1 ]
The classifier owning the behavior. The features of the context classifier as well as the elements visible to the context classifier are visible to the behavior.
  • parameter: Parameter
References a list of parameters to the behavior which describes the order and type of arguments that can be given when the behavior is invoked and of the values which will be returned when the behavior completes its execution. (Specializes Namespace.ownedMember.)
  • /formalParameter: Parameter
References a list of parameters to the behavior which describes the order and type of arguments that can be given when the behavior is invoked. Derived from Behavior.parameter by omitting those parameters who have direction=return.
  • /returnedResult: ReturnResult
References a sequence of parameters to the behavior which describes the order and type of values that will be returned when the behavior terminates. Derived from Behavior.parameter by selecting those parameters who have direction=return.
  • redefinedBehavior: Behavior
References a behavior that this behavior redefines. A subtype of Behavior may redefine any other subtype of Behavior. If the behavior implements a behavioral feature, it replaces the redefined behavior. If the behavior is a classifier behavior, it extends the redefined behavior.
  • precondition: Constraint
An optional set of Constraints specifying what must be fulfilled when the behavior is invoked. (Specializes Namespace.constraint and Constraint.context.)
  • postcondition: Constraint
An optional set of Constraints specifying what is fulfilled after the execution of the behavior is completed, if its precondition was fulfilled before its invocation. (Specializes Namespace.constraint and Constraint.context.)

Constraints

[1] The parameters of the behavior must match the parameters of the implemented behavioral feature.

[2] The implemented behavioral feature must be a feature (possibly inherited) of the context classifier of the behavior.

[3] If the implemented behavioral feature has been redefined in the ancestors of the owner of the behavior, then the behavior must realize the latest redefining behavioral feature.

[4] There may be at most one behavior for a given pairing of classifier (as owner of the behavior) and behavioral feature (as specification of the behavior).

Semantics

The detailed semantics of behavior is determined by its subtypes. The features of the context classifier and elements that are visible to the context classifier are also visible to the behavior, provided that is allowed by the visibility rules.

When a behavior is invoked, its attributes and parameters (if any) are created and appropriately initialized. Upon invocation, the arguments of the original invocation action are made available to the new behavior execution corresponding to its formal parameters, if any. When a behavior completes its execution, a value or set of values is returned corresponding to each return result parameter, if any. If such a parameter has a default value associated and the behavior does not explicitly generate a value for this parameter, the default value describes the value that will be returned corresponding to this parameter. If the invocation was synchronous, any return values from the behavior execution are returned to the original caller, which is unblocked and allowed to continue execution

The behavior executes within its context object, independently of and concurrently with any existing behavior executions.

The object which is the context of the behavior manages the input pool holding the events to which a behavior may respond (see BehavioredClassifier). As an object may have a number of behaviors associated, all these behaviors may access the same input pool. The object ensures that each event on the input pool is consumed by only one behavior.

When a behavior is instantiated as an object, it is its own context.

Semantic Variation Points

The means by which requests are transported to their target depend on the type of requesting action, the target, the properties of the communication medium, and numerous other factors. In some cases, this is instantaneous and completely reliable while in others it may involve transmission delays of variable duration, loss of requests, reordering, or duplication. (See also the discussion on page 371.)

How the parameters of behavioral features or a behavior match the parameters of a behavioral feature is a semantic variation point (see BehavioralFeature ).

Notation

None.

Changes from UML 1.x

This metaclass has been added. It abstracts the commonalities between the various ways that behavior can be implemented in the UML. It allows the various ways of implementing behavior (as expressed by the subtypes of Behavior) to be used interchangeably.

BehavioralFeature (from BasicBehaviors, Communications, specialized)


Description

A behavioral feature is implemented (realized) by a behavior. A behavioral feature specifies that a classifier will respond to a designated request by invoking its implementing method.

Attributes

BasicBehaviors

  • isAbstract: Boolean
If true, then the behavioral feature does not have an implementation, and one must be supplied by a more specific element. If false, the behavioral feature must have an implementation in the classifier or one must be inherited from a more general element.

Communications

  • concurrency: CallConcurrencyKind
Specifies the semantics of concurrent calls to the same passive instance (i.e., an instance originating from a class with isActive being false). Active instances control access to their own behavioral features.

Associations

BasicBehaviors

  • method: Behavior
A behavioral description that implements the behavioral feature. There may be at most one behavior for a particular pairing of a classifier (as owner of the behavior) and a behavioral feature (as specification of the behavior).

Communications
Constraints

No additional constraints.

Semantics

The invocation of a method is caused by receiving a request invoking the behavioral feature specifying that behavior. The details of invoking the behavioral feature are defined by the subclasses of BehavioralFeature.

Semantic Variation Points

How the parameters of behavioral features or a behavior match the parameters of a behavioral feature is a semantic variation point. Different languages and methods rely on exact match (i.e., the type of the parameters must be the same), co-variant match (the type of a parameter of the behavior may be a subtype of the type of the parameter of the behavioral feature), contra-variant match (the type of a parameter of the behavior may be a supertype of the type of the parameter of the behavioral feature), or a combination thereof.

Changes from UML 1.x

The metaattributes isLeaf and isRoot have been replaced by properties inherited from RedefinableElement.

BehavioredClassifier (from BasicBehaviors)

Description

A classifier can have behavior specifications defined in its namespace. One of these may specify the behavior of the classifier itself.

Attributes

No additional attributes.

Associations
Constraints

If a behavior is classifier behavior, it does not have a specification.

Semantics

The behavior specifications owned by a classifier are defined in the context of the classifier. Consequently, the behavior specifications may reference features of the classifier. Any invoked behavior may, in turn, invoke other behaviors visible to its context classifier. When an instance of a behaviored classifier is created, its classifier behavior is invoked.

When an event is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the event may be saved for later triggered effect. An immediate effect is manifested by the invocation of a behavior as determined by the event. A triggered effect is manifested by the storage of the event in the input event pool of the object and the later consumption of the event by the execution of an ongoing behavior that reaches a point in its execution at which a trigger matches the event in the pool. At this point, a behavior may be invoked as determined by the event.

When an executing behavior owned by an object comes to a point where it needs a trigger to continue its execution, the input pool is examined for an event that satisfies the outstanding trigger or triggers. If an event satisfies one of the triggers, the event is removed from the input pool and the behavior continues its execution, as specified. Any data associated with the event are made available to the triggered behavior.

Semantic Variation Points

It is a semantic variation whether one or more behaviors are triggered when an event satisfies multiple outstanding triggers.

If an event in the pool satisfies no triggers at a wait point, it is a semantic variation point what to do with it.

The ordering of the events in the input pool is a semantic variation.

Notation

See "Classifier (from Kernel, Dependencies, PowerTypes)" .

Changes from UML 1.x

In UML 1.4, there was no separate metaclass for classifiers with behavior.

CallConcurrencyKind (from Communications)

Description

CallConcurrencyKind is an enumeration with the following literals:

  • sequential
No concurrency management mechanism is associated with the operation and, therefore, concurrency conflicts may occur. Instances that invoke a behavioral feature need to coordinate so that only one invocation to a target on any behavioral feature occurs at once.
  • guarded
Multiple invocations of a behavioral feature may occur simultaneously to one instance, but only one is allowed to commence. The others are blocked until the performance of the first behavioral feature is complete. It is the responsibility of the system designer to ensure that deadlocks do not occur due to simultaneous blocks.
  • concurrent
Multiple invocations of a behavioral feature may occur simultaneously to one instance and all of them may proceed concurrently.

Attributes

No additional attributes.

Associations

No additional associations.

Constraints

No additional constraints.

Semantics

Not applicable.

Notation

None.

Changes from UML 1.x

None.

CallTrigger (from Communications)

A call trigger specifies that a given behavior execution may be triggered by a call event.

Description

A call trigger represents the reception of a request to invoke a specific operation and specifies a call event. A call event is distinct from the call action that caused it. A call event may cause the invocation of a behavior that is the method of the operation referenced by the call request, if that operation is owned or inherited by the classifier that specified the receiver object.

Attributes

No additional attributes.

Associations

Constraints

No additional constraints.

Semantics

A call trigger specifies that a behavior will be triggered by a call event as caused by the object receiving a call request from some other object or from itself. The call event may result in the execution of the behavior that implements the called operation. A call event may, in addition, cause other responses, such as a state machine transition, as specified in the classifier behavior of the classifier that specified the receiver object. In that case, the additional behavior is invoked after the completion of the operation referenced by the call trigger.

A call event makes available any argument values carried by the received call request to all behaviors caused by this event (such as transition actions or entry actions).

Notation

None.

Changes from UML 1.x

This metaclass replaces CallEvent.

ChangeTrigger (from Communications)

A change trigger specifies that a behavior execution may trigger as the result of a change event.

Description

A change trigger specifies an event that occurs when a Boolean-valued expression becomes true as a result of a change in value of one or more attributes or associations. A change event is raised implicitly and is not the result of an explicit action.

Attributes

No additional attributes.

Associations
Constraints

No additional constraints.

Semantics

Each time the value of the change expression changes from false to true, a change event is generated.

Semantic Variation Points

It is a semantic variation when the change expression is evaluated. For example, the change expression may be continuously evaluated until it becomes true. It is further a semantic variation whether a change event remains until it is consumed, even if the change expression changes to false after a change event.

Notation

A change trigger is denoted by a Boolean expression.

Changes from UML 1.x

This metaclass replaces change event.

Class (from Communications, specialized)

Description

A class may be designated as active, i.e., each of its instance having its own thread of control, or passive, i.e., each of its instance executing within the context of some other object.

A class may also specify which signals the instances of this class handle.

Attributes
  • isActive: Boolean
Determines whether an object specified by this class is active or not. If true, then the owning class is referred to as an active class. If false, then such a class is referred to as a passive class.

Associations
Semantics

An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as "the object having its own thread of control".) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.

Notation

Presentation options

A class with the property isActive = true can be shown by a class box with an additional vertical bar on either side, as depicted in Figure 319.


Duration (from Time)

Description

A duration defines a value specification that specifies the temporal distance between two time expressions that specify time instants.

Attributes

  • firstTime:Boolean [0..2]
If the duration is between times of two NamedElements, there are two Boolean attributes, one for the start of the duration and one for the end of the duration. For each of these it holds that firstTime is true if the time information is associated with the first point in time of the NamedElement referenced by event, and false if it represents the last point in time of the NamedElement. If there is only one NamedElement referenced by event, then this attribute is irrelevant. The default value is true.

Associations

  • event: NamedElement [0..2]
Refers to the specification(s) that describes the starting TimeExpression and the ending TimeExpression of the Duration. If only one NamedElement is referenced, the duration is from the first point in time of that NamedElement until the last point in time of that NamedElement.

Constraints

No additional constraints.

Semantics

A Duration defines a ValueSpecification that denotes some duration in time. The duration is given by the difference in time between a starting point in time and an ending point in time.

If the ending point in time precedes the starting point in time the duration will still be positive assuming the starting point and ending points to swap.

Notation

A Duration is a value of relative time given in an implementaion specific textual format. Often a Duration is a non-negative integer expression representing the number of "time ticks" which may elapse during this duration.

Changes from UML 1.x

This metaclass has been added.

DurationConstraint (from Time)

Description

A DurationConstraint defines a Constraint that refers to a DurationInterval.

Attributes

No additional attributes.

Associations

No additional associations.

Constraints

No additional constraints.

Semantics

The semantics of a DurationConstraint is inherited from Constraints.

Notation

A DurationConstraint is shown as some graphical association between a DurationInterval and the constructs that it constrains. The notation is specific to the diagram type.

Examples

See example in Figure 320 where the TimeConstraint is associated with the duration of a Message and the duration between two EventOccurrences.


Changes from UML 1.x

This metaclass has been added.

DurationInterval (from Time)

Description

A DurationInterval defines the range between two Durations.

Attributes

No additional attributes.

Associations
Constraints

No additional constraints.

Semantics

None.

Notation

A DurationInterval is shown using the notation of Interval where each value specification element is a DurationExpression.

DurationObservationAction (from Time)

Description

A DurationObservationAction defines an action that observes duration in time.

Attributes

No additional attributes.

Associations
Constraints

No additional constraints.

Semantics

A DurationObservationAction measures a duration during a trace at runtime.

Notation

A Duration is depicted by text in the expression language used to denote a time value. It may be possible that a duration contains arithmetic operators.

A duration observation is when a duration is assigned to a write-once variable. The duration observation is associated with two NamedElements with lines.

durationobservation ::= write-once-attribute=duration

Examples

See example in Figure 321 where the duration observation records the duration of a message, i.e., the time between the sending and the reception of that message.



Changes from UML 1.x

This metaclass has been added.

Interface (from Communications, specialized)

Description

Adds the capability for interfaces to include receptions (in addition to operations).

Associations

Interval (from Time)

Description

An Interval defines the range between two value specifications.

Attributes

No additional attributes.

Associations

Constraints

No additional constraints.

Semantics

The semantics of an Interval is always related to Constraints in which it takes part.

Notation

An Interval is denoted textually by two ValueSpecifications separated by "..":

interval ::= valuespecification-min .. valuespecification-max

Changes from UML 1.x

This metaclass has been added.

IntervalConstraint (from Time)

Description

A IntervalConstraint defines a Constraint that refers to an Interval.

Attributes

No additional attributes.

Associations

No additional associations.

Constraints

No additional constraints.

Semantics

The semantics of an IntervalConstraint is inherited from Constraint. All traces where the constraints are violated are negative traces, i.e., if they occur in practice the system has failed.

Notation

An IntervalConstraint is shown as a graphical association between an Interval and the constructs that this Interval constrains. The concrete form is given in its subclasses.

Changes from UML 1.x

This metaclass has been added.

MessageTrigger (from Communications)

Description

A message trigger specifies the an observable event caused by a either a call or a signal. MessageTrigger is an abstract metaclass.

Attributes

No additional attributes.

Associations

No additional associations.

Constraints

No additional constraints.

Semantics

No additional semantics.

Notation

None.

Changes from UML 1.x

The metaclass has been added.

OpaqueExpression (from BasicBehaviors, specialized)

Description

Provides a mechanism for precisely defining the behavior of an opaque expression. An opaque expression is defined by a behavior restricted to return one result.

Attributes

No additional attributes.

Associations
  • behavior: Behavior [ 0..1 ]
Specifies the behavior of the opaque expression.
  • result: Parameter [ 0..1 ]
Restricts an opaque expression to return exactly one return result. When the invocation of the opaque expression completes, a single set of values is returned to its owner. This association is derived from the single return result parameter of the associated behavior.

Constraints

[1] The behavior must not have formal parameters.

[2] The behavior must have exactly one return result parameter.

Semantics

An opaque expression is invoked by the execution of its owning element. Anopaque expression does not have formal parameters and thus cannot be passed data upon invocation. It accesses its input data through elements of its behavioral description. Upon completion of its execution, a single value or a single set of values is returned to its owner.

 Operation (from Communications, as specialized)

Description

On operation may invoke both the execution of method behaviors as well as other behavioral responses.

Semantics

If an operation is not mentioned in a trigger of a behavior owned or inherited by the behaviored classifier owning the operation, then upon occurrence of a call event (representing the receipt of a request for the invocation of this operation) a resolution process is performed which determines the method behavior to be invoked, based on the operation and the data values corresponding to the parameters of the operation transmitted by the request. Otherwise, the call event is placed into the input pool of the object (see BehavioredClassifier ). If a behavior is triggered by this event, it begins with performing the resolution process and invoking the so determined method. Then the behavior continues its execution as specified.

Operations specify immediate or triggered effects (see "BehavioredClassifier" ).

Semantic Variation Points

Resolution specifies how a particular behavior is identified to be executed in response to the invocation of an operation, using mechanisms such as inheritance. The mechanism by which the behavior to be invoked is determined from an operation and the transmitted argument data is a semantic variation point. In general, this mechanism may be complicated to include languages with features such as before-after methods, delegation, etc. In some of these variations, multiple behaviors may be executed as a result of a single call. The following defines a simple object-oriented process for this semantic variation point.

Object-oriented resolution !When a call request is received, the class of the target object is examined for an owned operation with matching parameters (see "BehavioralFeature" ). If such operation is found, the behavior associated as method is the result of the resolution. Otherwise the parent classifier is examined for a matching operation, and so on up the generalization hierarchy until a method is found or the root of the hierarchy is reached. If a class has multiple parents, all of them are examined for a method. If a method is found in exactly one ancestor class, then that method is the result of the resolution. If a method is found in more than one ancestor class along different paths, then the model is ill-formed under this semantic variation.

If no method by the resolution process, then it is a semantic variation point what is to happen.

Reception (from Communications)

Description

A reception is a declaration stating 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.

Attributes

No additional attributes.

Associations

Constraints

[1] A Reception can not be a query.

not self.isQuery

[2] A passive class cannot have receptions.

Semantics

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 depends 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.)

Receptions specify triggered effects (see "BehavioredClassifier").

Notation

Receptions are shown using the same notation as for operations with the keyword «signal», as shown in Figure 322.



Changes from UML 1.x

None.

Signal (from Communications)

Description

A signal is a specification of type of send request instances communicated between objects. The receiving object handles the signal instance as specified by its receptions. The data carried by a send request and passed to it by the occurrence of the send invocation event that caused the request is represented as attributes of the signal instance. A signal is defined independently of the classifiers handling the signal.

Attributes

No additional attributes.

Associations

No additional associations.

Constraints

No additional constraints.

Semantics

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. An exception is also represented as signal and is typically used to indicate fault situations.

Notation

A signal is depicted by a classifier symbol with the keyword «signal».

Changes from UML 1.x

None.

SignalTrigger (from Communications)

A signal trigger represents the fact that a behavior may trigger based upon the receipt of an asynchronous signal instance.

A signal event may e.g. cause a state machine to trigger a transition.

Description

A signal event represents the receipt of an asynchronous signal. A signal event may cause a response, such as a state machine transition as specified in the classifier behavior of the classifier that specified the receiver object, if the signal referenced by the send request is mentioned in a reception owned or inherited by the classifier that specified the receiver object.

Attributes

Associations

No additional associations.

Constraints

No additional constraints.

Semantics

A signal trigger specifies a signal event as caused by an object receiving a send request from some other object or from itself. A signal event may result in the execution of the behavior that implements the reception matching the received signal.

A signal event makes available any argument values carried by the received send request to all behaviors caused by this event (such as transition actions or entry actions).

Semantic Variation Points

The means by which requests are transported to their target depend on the type of requesting action, the target, the properties of the communication medium, and numerous other factors. In some cases, this is instantaneous and completely reliable while in others it may involve transmission delays of variable duration, loss of requests, reordering, or duplication. (See also the discussion on page 371.)

Notation

See Trigger.

Changes from UML 1.x

This metaclass replaces SignalEvent.

TimeConstraint (from Time)

Description

A TimeConstraint defines a Constraint that refers to a TimeInterval.

Attributes

No additional attributes.

Associations

No additional associations.

Constraints

No additional constraints.

Semantics

The semantics of a TimeConstraint is inherited from Constraints. All traces where the constraints are violated are negative traces i.e. if they occur in practice the system has failed.

Notation

A TimeConstraint is shown as graphical association between a TimeInterval and the construct that it constrains. Typically this graphical association is a small line, e.g., between an EventOccurrence and a TimeInterval.

Examples

See example in Figure 323 where the TimeConstraint is associated with the reception of a Message.



Changes from UML 1.x

This metaclass has been added.

TimeExpression (from Time)

Description

A Time Expression defines a value specification that represent a time value.

Attributes

firstTime:Boolean True if the TimeExpression describes the first point in time of the NamedElement referenced by event, in cases where the NamedElement describes something which extends in time. False if the TimeExpression describes the last point in time for the referenced NamedElement.

Associations
Constraints

No additional constraints.

Semantics

A TimeExpression denotes a time value.

Notation

A TimeExpression is a value of absolute time given in an implementation specific textual format. Often a TimeExpression is a non-negative integer expression representing the number of "time ticks" after some given starting point.

Changes from UML 1.x

This metaclass has been added.

TimeInterval (from Time)


Description

A TimeInterval defines the range between two TimeExpressions.

Attributes

No additional attributes.

Associations

Constraints

No additional constraints.

Semantics

None.

Notation

A TimeInterval is shown with the notation of Interval where each value specification element is a TimeExpression.

Changes from UML 1.x

This metaclass has been added.

TimeObservationAction (from Time)

Description

A TimeObservationAction defines an action that observes the current point in time.

Attributes

No additional attributes.

Associations
Constraints

No additional constraints.

Semantics

A TimeObservationAction is an action that, when executed, returns the current value of time in the context in which it is executing.

Notation

A TimeExpression is depicted by text in the expression language used to denote a time value. It may be possible that a time value contains arithmetic operators. The time expression is associated with a NamedElement with a line. A time observation action assigns a time expression to a write-once attribute.



Changes from UML 1.x

This metaclass has been added.

TimeTrigger (from Communications)

A TimeTrigger is a trigger that specifies when a time event will be generated. The time event occurs at the instant when a specified point in time has transpired.

Description

A time trigger specifies a time event, which models the expiration of a specific deadline.

Attributes
Associations
Constraints

No additional constraints.

Semantics

The expression specifying the deadline may be relative or absolute. If the time trigger is relative, a starting time must be defined.

Semantic Variation Points

There may be a variable delay between the time of reception and the time of dispatching of the TimeEvent (e.g., due to queueing delays).

Notation

A relative time trigger is specified with the keyword `after' followed by an expression that evaluates to a time value, such as "after (5 seconds)". An absolute time trigger is specified as an expression that evaluates to a time value, such as "Jan. 1, 2000, Noon".

Changes from UML 1.x

This metaclass replaces TimeEvent. The attribute isRelative has been added for clarity.

Trigger (from Communications)

A trigger specifies the an event that may cause the execution of an associated behavior.

Description

A trigger specifies the an event that may cause the execution of an associated behavior. An event is often ultimately caused by the execution of an action, but need not be. Trigger is an abstract metaclass.

Attributes

No additional attributes.

Associations
Constraints

No additional constraints.

Semantics

Events may cause execution of behavior, e.g the execution of the effect activity of a transition in a state machine. A triggers specifies the event that may trigger a behavior execution as well as any constraints on the event to filter out events not of interest. Based upon the different kinds of events that may trigger behavior execution, triggers are classified into signal trigger, call trigger, change trigger and time trigger, specifying that a behavior might be triggered by a signal
event, call event, change event, or time event, respectively.

Events are often generated as a result of some action either within the system or in the environment surrounding the system. Upon their occurrence, events are placed into the input pool of the object where they occurred (see BehavioredClassifier). An event is dispatched when it is taken from the input pool and either directly cause
the occurrence of a behavior or are delivered to the classifier behavior of the receiving object for processing. At this point, the event is considered consumed and referred to as the current event. A consumed event is no longer available for processing.

Semantic Variation Points

No assumptions are made about the time intervals between event occurrence, event dispatching, and consumption. This leaves open the possibility of different semantic variations such as zero-time semantics.

It is a semantic variation whether an event is discarded if there is no appropriate trigger defined for them.

Notation

A trigger is denoted by a list of names of the triggering events, followed by an assignment specification:

event-name-list [ `(' assignment-specification `)' ]

where the assignment-specification is a comma separated list of items, where each item may be of the form

Changes from UML 1.x

The corresponding metaclass in 1.x was Event. In 1.x, events were specified with Parameters. Instead, the data that may be communicated by an event is accessed via the properties of the specification element defining the event. In UML 2.0, the term "event" means an occurrence of an event of a particular type, whereas in UML 1.x, that same term indicated the event type.