Class Descriptions


CombinedFragment (from Fragments)

A combined fragment defines an expression of interaction fragments. A combined fragment is defined by an interaction operator and corresponding interaction operands. Through the use of CombinedFragments the user will be able to describe a number of traces in a compact and concise manner.
CombinedFragment is a specialization of InteractionFragment.

Attributes

Associations
Constraints

[1] If the interactionOperator is opt, loop or neg there must be exactly one operand

[2] The InteractionConstraint with minint and maxint only apply when attached to an InteractionOperand where the interactionOperator is loop.

Semantics

The semantics of a CombinedFragment is dependent upon the interactionOperator as explained below.

Alternatives

The interactionOperator alt designates that the CombinedFragment represents a choice of behavior. At most one of the operands will execute. The operand that executes must have an explicit or implicit guard expression that evaluates to true at this point in the interaction. An implicit true guard is implied if the operand has no guard.

The set of traces that defines a choice is the union of the (guarded) traces of the operands.

An operand guarded by else designates a guard that is the negation of the disjunction of all other guards in the enclosing

CombinedFragment.

Option

The interactionOperator opt designates that the CombinedFragment represents a choice of behavior where either the (sole) operand happens or nothing happens. An option is semantically equivalent to an alternative CombinedFragment where there is one operand with non-empty content and the second operand is empty.

Break

The interactionOperator break designates that the CombinedFragment represents a breaking scenario in the sense that the operand is a scenario that is performed instead of the remainder of the enclosing InteractionFragment. Thus the break operator is a shorthand for an Alternative operator where one operand is given and the other assumed to be the rest of the enclosing InteractionFragment.

Break CombinedFragments must be global relative to the enclosing InteractionFragment.

Parallel

The interactionOperator par designates that the CombinedFragment represents a parallel merge between the behaviors of the operands. The eventoccurrences of the different operands can be interleaved in any way as long as the ordering imposed by each operand as such is preserved.

A parallel merge defines a set of traces that describes all the ways that eventoccurrences of the operands may be interleaved without obstructing the order of the eventoccurrences within the operand.

Weak Sequencing

The interactionOperator seq designates that the CombinedFragment represents a weak sequencing between the behaviors of the operands.

Weak sequencing is defined by the set of traces with these properties:
  1. The ordering of eventoccurrences within each of the operands are maintained in the result
  2. Eventoccurrences on different lifelines from different operands may come in any order.
  3. Eventoccurrences on the same lifeline from different operands are ordered such that an eventoccurrence of the first operand comes before that of the second operand.
Thus weak sequencing reduces to a parallel merge when the operands are on disjunct sets of participants. Weak sequencing reduces to strict sequencing when the operands work on only one participant.

Strict Sequencing

The interactionOperator strict designates that the CombinedFragment represents a strict sequencing between the behaviors of the operands. The semantics of the strict operation defines a strict ordering of the operands on the first level within the CombinedInteraction with operator strict. Therefore eventoccurrences within contained CombinedInteractions will not directly be compared with other eventoccurrences of the enclosing CombinedInteraction.

Negative

The interactionOperator neg designates that the CombinedFragment represents traces that are defined to be invalid.

The set of traces that defined a negative CombinedFragment is equal to the set of traces given by its (sole) operand, only that this set is a set of invalid rather than valid traces. All InteractionFragments that are different from Negative are considered positive meaning that they describe traces that are valid and should be possible.

Critical Region

The interactionOperator critical designates that the CombinedFragment represents a critical region. A critical region means that the traces of the region cannot be interleaved by other Eventoccurrences (on those Lifelines covered by the region). This means that the region is treated atomically by the enclosing fragment when determining the set of valid traces. Even though enclosing CombinedFragments may imply that some Eventoccurrences may interleave into the region, such as e.g. with par-operator, this is prevented by defining a region.

Thus the set of traces of enclosing constructs are restricted by critical regions.



The example in Figure 332 shows that the handling of a 911-call must be contiguously handled. For the operator he must make sure to forward the 911-call before doing anything else. The normal calls, however, can be freely interleaved.

Ignore / Consider

The interactionOperator ignore designates that there are some message types that are not shown within this combined fragment. These message types can be considered insignificant and are intuitively ignored if they appear in a corresponding execution. Alternatively one can understand ignore to mean that the messages that are ignored can appear anywhere in the traces.

Conversely the interactionOperator consider designates which messages should be considered within this CombinedFragment. This is equivalent to defining every other message to be ignored.

Assertion

The interactionOperator assert designates that the CombinedFragment represents an assertion. The sequences of the operand of the assertion are the only valid continuations. All other continuations result in an invalid trace.

Assertions are often combined with Ignore or Consider as shown in Figure 345.

Loop

The interactionOperator loop designates that the CombinedFragment represents a loop. The loop operand will be repeated a number of times.

The Guard may include a lower and an upper number of iterations of the loop as well as a Boolean expression. The semantics is such that a loop will iterate minimum the `minint' number of times (given by the iteration expression in the guard) and at most the `maxint' number of times. After the minimum number of iterations have executed, and the boolean expression is false the loop will terminate. The loop construct represent a recursive application of the seq operator where the loop operand is sequenced after the result of earlier iterations.

The Semantics of Gates (see also "Gate (from Fragments)" )

The gates of a CombinedFragment represent the syntactic interface between the CombinedFragment and its surroundings, which means the interface towards other InteractionFragments.

The only purpose of gates is to define the source and the target of Messages or General Order relations.

Notation

The notation for a CombinedFragment in a Sequence Diagram is a solid-outline rectangle. The operator is shown in a pentagon in the upper left corner of the rectangle.

More than one operator may be shown in the pentagon descriptor. This is a shorthand for nesting CombinedFragments.

This means that sd strict in the pentagon descriptor is the same as two CombinedFragments nested, the outermost with sd and the inner with strict.

The operands of a CombinedFragment are shown by tiling the graph region of the CombinedFragment using dashed horizontal lines to divide it into regions corresponding to the operands.

Strict

Notationally this means that the vertical coordinate of the contained fragments is significant throughout the whole scope of the CombinedFragment and not only on one Lifeline. The vertical position of an EventOccurrence is given by the vertical position of the corresponding point. The vertical position of other InteractionFragments is given by the topmost vertical position of its bounding rectangle.

Ignore / Consider

Textual syntax: (ignore | consider ){ <message name>{,<message name>}* }

Examples: consider {m, s}: showing that only m and s messages are considered significant
                ignore {q,r}: showing that q and r messages are considered insignificant

Ignore and consider operations are typically combined with other operations such as "assert consider {m, s}"

See example in Figure 345.

Loop

Textual syntax of the loop operand: loop [ `(` <minint> [, <maxint> ] `)' ]

<minint>
    ::= non-negative natural
<maxint>
    ::= non-negative natural (greater than or equal to <minint> | `*'

 `*' means infinity.

If only <minint> is present, this means that minint=maxint=integer.

If only loop then this means a loop with infinity upper bound and with 0 as lower bound.

Presentation Option for "coregion area"

A notational shorthand for parallel combined fragments are available for the common situation where the order of event occurrences (or other nested fragments) on one Lifeline is insignificant. This means that in a given "coregion" area of a Lifeline all the directly contained fragments are considered separate operands of a parallel combined fragment. See example in Figure 333.

Examples



Rationale

Not applicable.

Changes from UML 1.x

This concept was not included in UML 1.x.

Continuation (from Fragments)


A Continuation is a syntactic way to define continuations of different branches of an Alternative CombinedFragment.

Continuations is intuitively similar to labels representing intermediate points in a flow of control.

Attributes
Constraints

[1] Continuations with the same name may only cover the same set of Lifelines (within one Classifier).

[2] Continuations are always global in the enclosing InteractionFragment e.g. it always covers all Lifelines covered by the enclosing InteractionFragment.

[3] Continuations always occur as the very first InteractionFragment or the very last InteractionFragment of the enclosing InteractionFragment.

Semantics

Continuations have semantics only in connection with Alternative CombinedFragments and (weak) sequencing.

If an InteractionOperand of an Alternative CombinedFragment ends in a Continuation with name (say) X, only InteractionFragments starting with the Continuation X (or no continuation at all) can be appended.

Notation

Continuations are shown with the same symbol as States, but they may cover more than one Lifeline.

Continuations may also appear on flowlines of Interaction Overview Diagrams.

Continuations that are alone in an InteractionFragment is considered to be at the end of the enclosing InteractionFragment.



The two diagrams in Figure 334 are together equivalent to the diagram in Figure 335.



EventOccurrence (from BasicInteractions)

EventOccurrences represents moments in time to which Actions are associated. An EventOccurrence is the basic semantic unit of Interactions. The sequences of Eventoccurrences are the meanings of Interactions. Messages are sent through either asynchronous signal sending or operation calls. Likewise they are recieved by Receptions or actions of consumption.

EventOccurrence is a specialization of InteractionFragment and of MessageEnd.

EventOccurrences are ordered along a Lifeline.

The namespace of an EventOccurrence is the Interaction in which it is contained.

Associations
Semantics

The semantics of an EventOccurrence is just the trace of that single EventOccurrence.

The understanding and deeper meaning of the Eventoccurrence is dependent upon the associated Message and the information that it conveys.

Notation

Eventoccurrences are merely syntactic points at the ends of Messages or at the beginning/end of an ExecutionOccurrence.

Examples



ExecutionOccurrence (from BasicInteractions)

An ExecutionOccurrence is an instantiation of a unit of behavior within the Lifeline. Since the ExecutionOccurrence will have some duration, it is represented by two Eventoccurrences, the start EventOccurrence and the finish EventOccurrence.

An ExecutionOccurrence is an InteractionFragment.

Associations
Constraints

[1] The startEvent and the finishEvent must be on the same Lifeline

start.lifeline = finish.lifeline

Semantics

The trace semantics of Interactions merely see an ExecutionOccurrence as the trace <start, finish>. There may be Eventoccurrences between these. Typically the start Eventoccurrence and the finish Eventoccurrence will refer to Eventoccurrences such as a receive Eventoccurrence (of a Message) and the send Eventoccurrence (of a return Message).

Notation

ExecutionOccurences are represented as thin rectangles (grey or white) on the lifeline (see "Lifeline (from BasicInteractions, Fragments)" ).

We may also represent an ExecutionOccurrence as Actions are represented in Activity diagrams.

ExecutionOccurrences that refer to atomic actions such as reading attributes of a Signal (conveyed by the Message), the Action symbol may be associated with the reception EventOccurrence with a line in order to emphasize that the whole Action is associated with only one EventOccurrence (and start and finish associations refer the very same EventOccurrence)

Gate (from Fragments)

A Gate is a connection point for relating a Message outside an InteractionFragment with a Message inside the InteractionFragment.

Gate is a specialization of MessageEnd.

Gates are connected through Messages. A Gate is actually a representative of an EventOccurrence that is not in the same scope as the Gate.

Gates play different roles: we have formal gates on Interactions, actual gates on InteractionOccurrences, expression gates on CombinedFragments.

Constraints

[1] The message leading to/from an actualGate of an InteractionOccurrence must correspond to the message leading from/to the formalGate with the same name of the Interaction referenced by the InteractionOccurrence.

[2] The message leading to/from an (expression) Gate within a CombinedFragment must correspond to the message leading from/to the CombinedFragment on its outside.

Semantics

The gates are named either explicitly or implicitly. Gates may be identified either by name (if specified), or by a constructed identifier formed by concatenating the direction of the message and the message name (e.g. out_CardOut).

The gates and the messages between gates have one purpose, namely to establish the concrete sender and receiver for every message.

Notation

Gates are just points on the frame, the ends of the messages. They may have an explicit name. See Figure 336.

The same gate may appear several times in the same or different diagrams.

GeneralOrdering (from BasicInteractions)

A GeneralOrdering represents a binary relation between two Eventoccurrences, to describe that one Eventoccurrence must occur before the other in a valid trace. This mechanism provides the ability to define partial orders of EventOccurrences that may otherwise not have a specified order.
A GeneralOrdering is a specialization of NamedElement.

A GeneralOrdering may appear anywhere in an Interaction, but only between Eventoccurrences.

Associations
Semantics

A GeneralOrdering is introduced to restrict the set of possible sequences. A partial order of Eventoccurrences is defined by a set of GeneralOrdering.

Notation

A GeneralOrdering is shown by a dotted line connected the two Eventoccurrences. The direction of the relation from the before to the after is given by an arrowhead placed somewhere in the middle of the dotted line (i.e. not at the endpoint).

Interaction (from BasicInteraction, Fragments)

An interaction is a unit of behavior that focuses on the observable exchange of information between ConnectableElements.

An Interaction is a specialization of InteractionFragment and of Behavior.

Associations
Semantics

Interactions are units of behavior of an enclosing Classifier. Interactions focus on the passing of information with Messages between the ConnectableElements of the Classifier.

The semantics of an Interaction is given as a pair of sets of traces. The two trace sets represent valid traces and invalid traces. The union of these two sets need not necessarily cover the whole universe of traces. The traces that are not included are not described by this Interaction at all, and we cannot know whether they are valid or invalid.

A trace is a sequence of Eventoccurrences. The semantics of Interactions are compositional in the sense that the semantics of an Interaction is mechanically built from the semantics of its constituent InteractionFragments. The constituent InteractionFragments are ordered and combined by the seq operation (weak sequencing) as explained in "Weak Sequencing".

The invalid set of traces are associated only with the use of a Negative CombinedInteraction. For simplicity we describe only valid traces for all other constructs.

As Behavior an Interaction is generalizable and redefineable. Specializing an Interaction is simply to add more traces to those of the original. The traces defined by the specialization is combined with those of the inherited Interaction with a union.

The classifier owning an Interaction may be specialized, and in the specialization the Interaction may be redefined.

Redefining an Interaction simply means to exchange the redefining Interaction for the redefined one, and this exchange takes effect also for InteractionOccurrences within the supertype of the owner. This is similar to redefinition of other kinds of Behavior.

Basic trace model: The semantics of an Interaction is given by a pair [P, I] where P is the set of valid traces and I is the set of invalid traces. P I needs not be the whole universe of traces.

A trace is a sequence of event occurrences denoted <e1, e2, ... , en>.

An event occurrence will also include information about the values of all relevant objects at this point in time.

Each construct of Interactions (such as CombinedFragments of different kinds) are expressed in terms of how it relates to a pair of sets of traces. For simplicity we normally refer only to the set of valid traces as these traces are those mostly modeled.

Two Interactions are equivalent if their pair of trace-sets are equal.

Relation of trace model to execution model: In Chapter 13, "Common Behaviors" we find an Execution model, and this is how the Interactions Trace Model relates to the Execution model.

An Interaction is an Emergent Behavior.

An Invocation Event in the Execution model corresponds with an EventOccurrence in Interactions. Normally in Interaction the action leading to the invocation as such is not described (such as the sending action). However, if it is desirable to go into details, a Behavior (such as an Activity) may be associated with an Eventoccurrence. An Eventoccurrence in Interactions are normally interpreted to take zero time. Duration is always between Eventoccurrences.

Likewise a Receiving Event in the Execution model corresponds with an Eventoccurrence in Interactions. Similarly the detailed actions following immediately from this reception is often omitted in Interactions, but may also be described explicitly with a Behavior associated with that Eventoccurrence.

A Request in the Execution model corresponds to the Message in Interactions.

A BehaviorExecution in the Execution model corresponds directly to an Execution Occurrence in Interactions. An ExecutionOccurrence is defined in the trace by two EventOccurrences, one at the start and one at the end. This corresponds to the Start Event and the Termination Event of the Execution model

Notation

The notation for an Interaction in a Sequence Diagram is a solid-outline rectangle. The keyword sd followed by the Interaction name and parameters is in a pentagon in the upper left corner of the rectangle. The notation within this rectangular frame comes in several forms: Sequence Diagrams, Communication Diagrams, Interaction Overview Diagrams and Timing Diagrams.

The notation within the pentagon descriptor follows the general notation for the name of Behaviors. In addition the Interaction Overview Diagrams may include a list of Lifelines through a lifeline-clause as shown in Figure 349. The list of lifelines is simply a listing of the Lifelines involved in the Interaction. An Interaction Overview Diagram does not in itself show the involved lifelines even though the lifelines may occur explicitly within inline Interactions in the graph nodes.

An Interaction diagram may also include definitions of local attributes with the same syntax as attributes in general are shown within class symbol compartments. These attribute definitions may appear near the top of the diagram frame or within note symbols other places in the diagram.

Please refer to Section 14.4 to see examples of notation for Interactions.
Examples


The example in Figure 337 shows three messages communicated between two (anonymous) lifelines of types User and ACSystem. The message CardOut overtakes the message OK in the way that the receiving event occurrences are in the opposite order of the sending eventoccurrences. Such communication may occur when the messages are asynchronous.

Finally a fourth message is sent from the ACSystem to the environment through a gate with implicit name out_Unlock.

The local attriburte PIN of UserAccepted is declared near the diagram top. It could have been declared in a Note somewhere else in the diagram.

Rationale

Not applicable.

Changes from UML 1.x

Interactions are now contained within Classifiers and not only within Collaborations. Their participants are modeled by Lifelines instead of ClassifierRoles.

InteractionConstraint (from Fragments)

An InteractionConstraint is a boolean expression that guards an operand in a CombinedFragment.

InteractionConstraint is a specialization of Constraint.

Furthermore the InteractionConstraint contains two expressions designating the minimum and maximum number of times a loop CombinedFragment should execute.

Associations
Constraints

[1] The dynamic variables that take part in the constraint must be owned by the ConnectableElement corresponding to the covered Lifeline.

[2] The constraint may contain references to global data or write-once data.

[3] Minint/maxint can only be present if the InteractionConstraint is associated with the operand of a loop CombinedFragment.

[4] If minint is specified, then the expression must evaluate to a non-negative integer.

[5] If maxint is specified, then the expression must evaluate to a positive integer.

[6] If maxint is specified, then minint must be specified and the evaluation of maxint must be >= the evaluation of minint

Semantics

InteractionConstraints are always used in connection with CombinedFragments, see "CombinedFragment (from Fragments)" .

Notation

An InteractionConstraint is shown in square brackets covering the lifeline where the first event occurrence will occur, positioned above that event, in the containing Interaction or InteractionOperand.

interactionconstraint ::= [`[` Boolean Expression | else`]']

When the InteractionConstraint is omitted, true is assumed.
Please refer to an example of InteractionConstraints in Figure 333.

InteractionFragment (from Fragments)

InteractionFragment is an abstract notion of the most general interaction unit. An interaction fragment is a piece of an interaction. Each interaction fragment is conceptually like an interaction by itself.

InteractionFragment is an abstract class and a specialization of NamedElement.

Associations

Semantics

The semantics of an InteractionFragment is a pair of set of traces. See "Interaction (from BasicInteraction, Fragments)" for explanation of how to calculate the traces.

Notation

There is no general notation for an InteractionFragment. The specific subclasses of InteractionFragment will define their own notation.

Rationale

Not applicable.

Changes from UML 1.x

This concept did not appear in UML 1.x.

InteractionOccurrence (from Fragments)

An InteractionOccurrence refers to an Interaction. The InteractionOccurrence is a shorthand for copying the contents of the referred Interaction where the InteractionOccurrence is. To be accurate the copying must take into account substituting parameters with arguments and connect the formal gates with the actual ones.

It is common to want to share portions of an interaction between several other interactions. An InteractionOccurrence allows multiple interactions to reference an interaction that represents a common portion of their specification.

Description

InteractionOccurrence is a specialization of InteractionFragment.

An InteractionOccurrence has a set of actual gates that must match the formal gates of the referenced Interaction.

Associations

Constraints

[1] Actual Gates of the InteractionOccurrence must match Formal Gates of the referred Interaction. Gates match when their names are equal.
        TBD

[2] The InteractionOccurrence must cover all Lifelines of the enclosing Interaction which appear within the referred Interaction.

[3] The arguments of the InteractionOccurrence must correspond to parameters of the referred Interaction

[4] The arguments must only be constants, parameters of the enclosing Interaction or attributes of the classifier owning the enclosing Interaction.

Semantics

The semantics of the InteractionOccurrence is the set of traces of the semantics of the referred Interaction where the gates have been resolved as well as all generic parts having been bound such as the arguments substituting the parameters.

Notation

The InteractionOccurrence is shown as a CombinedFragment symbol where the operator is called ref. The complete syntax of the name (situated in the InteractionOccurrence area) is:

name ::=[ attribute-name = ][collaborationoccurrence.] interactionname[`(`arguments')'] [: return-value]
argument ::= in-argument [ out out-argument]

The attribute-name refers to an attribute of one of the lifelines in the Interaction.

The collaborationoccurence is an identification of a collaboration occurrence that binds lifelines of a collaboration. The interaction name is in that case within that collaboration. See example of the usage of collaboration occurrences in Figure 346.

The arguments are most often arguments of IN-parameters. If there are OUT- or INOUT-parameters and the output value is to be described, this can be done following an out keyword.

For general syntax of arguments we use the same syntax as for Messages ("Message (from BasicInteractions)" ).

If the InteractionOccurrence returns a value, this may be described following a colon at the end of the clause.

Examples

In Figure 338 we show an InteractionOccurrence referring the Interaction EstablishAccess with (input) argument "Illegal PIN". Within the optional CombinedFragment there is another InteractionOccurrence without arguments referring OpenDoor.


In Figure 339 we have a more advanced Interaction that models a behavior returning a Verdict value. The return value from the Interaction is shown as a separate Lifeline a_op_b. Inside the Interaction there is an InteractionOccurrence referring a_util_b with value return to the attribute xc of :xx with the value 9, and with inout parameter where the argument is w with returning out-value 12.

Rationale

Not applicable.

Changes from UML 1.x

InteractionOccurrence was not a concept in UML 1.x

InteractionOperand (from Fragments)

An InteractionOperand is contained in a CombinedFragment. An InteractionOperand represent one operand of the expression given by the enclosing CombinedFragment.

An InteractionOperand is an InteractionFragment with an optional guard expression. An InteractionOperand may be guarded by a InteractionConstraint. Only InteractionOperands with a guard that evaluates to true at this point in the interaction will be considered for the production of the traces for the enclosing CombinedFragment.

InteractionOperand contains an ordered set of InteractionFragments.

In Sequence Diagrams these InteractionFragments are ordered according to their geometrical position vertically. The geometrical position of the InteractionFragment is given by the topmost vertical coordinate of its contained eventoccurrences or symbols.

Associations
Constraints

[1] The guard must be placed directly prior to (above) the eventoccurrence that will become the first eventoccurrence within this InteractionOperand

[2] The guard must contain only references to values local to the Lifeline on which it resides, or values global to the whole Interaction (See "InteractionConstraint (from Fragments)" ).

Semantics

Only InteractionOperands with true guards are included in the calculation of the semantics. If no guard is present, this is taken to mean a true guard.

The semantics of an InteractionOperand is given by its constituent InteractionFragments combined by the implicit seq operation. The seq operator is described in "CombinedFragment (from Fragments)"

Notation

InteractionOperands are separated by a dashed horizontal line. The InteractionOperands together make up the framed CombinedFragment.

Within an InteractionOperand of a Sequence Diagram the order of the InteractionFragments are given simply by the topmost vertical position.

See Figure 333 for examples of InteractionOperand.

InteractionOperator (from Fragments)

Interaction Operator is an enumeration designating the different kinds of operators of CombinedFragments.

The InteractionOperand defines the type of operator of a CombinedFragment.

Literals
Semantics

The value of the InteractionOperator is significant for the semantics of "CombinedFragment (from Fragments)".

Notation

The value of the InteractionOperand is given as text in a small compartment in the upper left corner of the CombinedFragment frame.

See Figure 333 for examples of InteractionOperator.

Lifeline (from BasicInteractions, Fragments)

A lifeline represents an individual participant in the Interaction. While Parts and StructuralFeatures may have multiplicity greater than 1, Lifelines represent only one interacting entity.

Lifeline is a specialization of NamedElement.

If the referenced ConnectableElement is multivalued (i.e. has a multiplicity > 1), then the Lifeline may have an expression (the `selector') that specifies which particular part is represented by this Lifeline. If the selector is omitted this means that an arbitrary representative of the multivalued ConnectableElement is chosen.

Associations
Constraints

[1] If two (or more) InteractionOccurrences within one Interaction, refer to Interactions with common Lifelines, those Lifelines must also appear in the Interaction with the InteractionOccurrences. By `common Lifelines' we mean Lifelines with the same selector and represents associations.

    TBD

[2] The selector for a Lifeline must only be specified if the referenced Part is multivalued.

(self.selector->isEmpty implies not self.represents.isMultivalued()) or
(not self.selector->isEmpty implies self.represents.isMultivalued())

[3] The classifier containing the referenced ConnectableElement must be the same classifier, or an ancestor, of the classifier that contains the interaction enclosing this lifeline.

Semantics

The order of Eventoccurrences along a Lifeline is significant denoting the order in which these Eventoccurrence will occur. The absolute distances between the Eventoccurrences on the Lifeline are, however, irrelevant for the semantics.

The semantics of the Lifeline (within an Interaction) is the semantics of the Interaction selecting only Eventoccurrences of this Lifeline.

Notation

A Lifeline is shown using a symbol that consists of a rectangle forming its "head" followed by a vertical line (which may be dashed) that represents the lifetime of the participant. Information identifying the lifeline is displayed inside the rectangle in the following format:

lifelineident ::= [connectable_element_name [`[` selector `]']] [: class_name] [decomposition] | self
selector ::= expression
decomposition ::= ref interactionident

class_name is the type referenced by the represented ConnectableElement.

Even though the syntax in principle allows it, a lifelineident cannot be empty.

The Lifeline head has a shape which is based on the classifier for the part that this lifeline represents. Often the head is a white rectangle containing the name.

If the name is the keyword self, then the lifeline represents the object of the classifier that encloses the Interaction that owns the Lifeline. Ports of the encloser may be shown separately even when self is included.

To depict method activations we apply a thin grey or white rectangle that covers the Lifeline line.

Examples

See Figure 337 where the Lifelines are pointed to.

See Figure 333 to see method activations.

Rationale

Not applicable.

Changes from UML 1.x

Lifelines are basically the same concept as before in UML 1.x.

Message (from BasicInteractions)


A Message defines a particular communication between Lifelines of an Interaction.

A Message is a NamedElement that defines one specific kind of communication in an Interaction. A communication can be e.g. raising a signal, invoking an Operation, creating or destroying an Instance. The Message specifies not only the kind of communication given by the dispatching ExecutionOccurrence, but also the sender and the receiver.

A Message associates normally two EventOccurrences - one sending EventOccurrence and one receiving EventOccurrence.

Attributes

  • messageKind:MessageKind
The derived kind of the Message (complete, lost, found or unknown)
complete = sendEvent and receiveEvent are present
lost = sendEvent present and receiveEvent absent
found = sendEvent absent and receiveEvent present
unknown = sendEvent and receiveEvent absent (should not appear)
  • messageSort:MessageSort
The sort of communication reflected by the Message (synchCall, synchSignal, asynchCall, asynchSignal)

Associations

Constraints

[1] If the sendEvent and the receiveEvent of the same Message are on the same Lifeline, the sendEvent must be ordered before the receiveEvent.

[2] The signature must either refer an Operation (in which case messageSort is either synchCall or asynchCall) or a Signal (in which case messageSort is either synchSignal or asynchSignal). The name of the NamedElement referenced by signaturemust be the same as that of the Message.

[3] In the case when the Message signature is an Operation, the arguments of the Message must correspond to the parameters  of the Operation. A Parameter corresponds to an Argument if the Argument is of the same Class or a specialization of that of the Parameter.

[4] In the case when the Message signature is a Signal, the arguments of the Message must correspond to the attributes of the Signal. A Message Argument corresponds to a Signal Attribute if the Arguement is of the same Class or a specialization of that of the Attribute.

[5] Relations sendEvent and receiveEvent are mutually exclusive.

[6] Arguments of a Message must only be:

i) attributes of the sending lifeline
ii) constants
iii) symbolic values (which are wildcard values representing any legal value)
iv) explicit parameters of the enclosing Interaction
v) attributes of the class owning the Interaction

[7] Messages cannot cross bounderies of CombinedFragments or their operands.

[8] If the MessageEnds are both EventOccurrences then the connector must go between the Parts represented by the Lifelines of the two MessageEnds.

Semantics

The semantics of a complete Message is simply the trace <sendEvent, receiveEvent>.

A lost message is a message where the sending event occurrence is known, but there is no receiving event occurrence. We interpret this to be because the message never reached its destination. The semantics is simply the trace <sendEvent>.

A found message is a message where the receiving event occurrence is known, but there is no (known) sending event occurrence. We interpret this to be because the origin of the message is outside the scope of the description. This may for example be noise or other activity that we do not want to describe in detail. The semantics is simply the trace <receiveEvent>.

A Message reflects either an Operation call and start of execution - or a sending and reception of a Signal.

When a Message represents an Operation the arguments of the Message are the arguments of the CallAction on the sending Lifeline and the arguments of the CallEvent on the receiving Lifeline.

When a Message represents a Signal, the arguments of the Message are the arguments of the SendAction on the sending Lifeline and on the receiving Lifeline the arguments are available in the SignalEvent.

If the Message represents a CallAction, There will normally be a return message from the called lifeline back to the calling lifeline before the calling Lifeline will proceed.

Notation

A message is shown as a line from the sender message end to the receiver message end. The form of the line or arrowhead reflect properties of the message:

Asynchronous Messages have an open arrow head.

Synchronous Messages typically represent method calls and are shown with a filled arrow head. The reply message from a method has a dashed line.

Object creation Message has a dashed line with an open arrow.

Lost Messages are described as a small black circle at the arrow end of the Message.

Found Messages are described as a small black circle at the starting end of the Message.

On Communication Diagrams, the Messages are decorated by a small arrow along the connector close to the Message name and sequence number in the direction of the Message.

Syntax for the Message name is the following:

messageident ::= [attribute =] signal-or-operation-name [ ( arguments) ][: return-value] | `*'
arguments ::= argument [ , arguments]
argument ::= [parameter-name=]argument-value | attribute= out-parameter-name [:argument-value]| -

Messageident equalling `*' is a shorthand for more complex alternative CombinedInteraction to represent a message of any type. This is to match asterisk triggers in State Machines.

Return-value and attribute assignment are used only for reply messages. Attribute assignment is a shorthand for including the Action that assigns the return-value to that attribute. This holds both for the possible return value of the message (the return value of the associated operation), and the out values of (in)out parameters.
When the argument list contains only argument-values, all the parameters must be matched either by a value or by a dash (-). If parameter-names are used to identify the argument-value, then arguments may freely be omitted. Omitted parameters get an unknown argument-value.

Examples

In Figure 337 we see only asynchronous Messages. Such Messages may overtake each other.
In Figure 333 we see method calls that are synchronous accompanied by replies. We also see a Message that represents the creation of an object.
In Figure 348 we see how Messages are denoted in Communication Diagrams.

Examples of syntax
:
mymessage(14, - , 3.14, "hello") // second argument is undefined
v=mymsg(16, variab):96 // this is a reply message carrying the return value 96 assigning it to v
mymsg(myint=16) // the input parameter `myint' is given the argument value 16

See Figure 333 for a number of different applications of the textual syntax of message identification.

Rationale

Not applicable.

Changes from UML 1.x

We notice that Messages may have Gates on either end.

MessageEnd (from BasicInteractions)

A MessageEnd is an abstract NamedElement that represents what can occur at the end of a Message.

Associations
Semantics

Subclasses of MessageEnd define the specific semantics appropriate to the concept they represent.

PartDecomposition (from Fragments)

PartDecomposition is a description of the internal interactions of one Lifeline relative to an Interaction.

A Lifeline has a class associated as the type of the ConnectableElement that the Lifeline represents. That class may have an internal structure and the PartDecomposition is an Interaction that describes the behavior of that internal structure relative to the Interaction where the decomposition is referenced.

A PartDecomposition is a specialization of InteractionOccurrence. It associates with the ConnectableElement that it decomposes.

Constraints

[1] PartDecompositions apply only to Parts that are Parts of Internal Structures not to Parts of Collaborations.

[2] Assume that within Interaction X, Lifeline L is of class C and decomposed to D. Within X there is a sequence of constructs along L (such constructs are CombinedFragments, InteractionOccurrence and (plain) Eventoccurrences). Then a corresponding sequence of constructs must appear within D, matched one-to-one in the same order.

i) CombinedFragment covering L are matched with an extra-global CombinedFragment in D
ii) An InteractionOccurrence covering L are matched with a global (i.e. covering all Lifelines) InteractionOccurrence in D.
iii) A plain EventOccurrence on L is considered an actualGate that must be matched by a formalGate of D

[3] Assume that within Interaction X, Lifeline L is of class C and decomposed to D. Assume also that there is within X an InteractionOccurrence (say) U that covers L. According to the constraint above U will have a counterpart CU within D.Within the Interaction referenced by U, L should also be decomposed, and the decomposition should reference CU. (This rule is called commutativity of decomposition)

Semantics

Decomposition of a lifeline within one Interaction by an Interaction (owned by the type of the Lifeline's associated ConnectableElement), is interpreted exactly as an InteractionOccurrence. The messages that go into (or go out from) the decomposed lifeline are interpreted as actual gates that are matched by corresponding formal gates on the decomposition.

Since the decomposed Lifeline is interpreted as an InteractionOccurrence, the semantics of a PartDecomposition is the semantics of the Interaction referenced by the decomposition where the gates and parameters have been matched.

That a CombinedFragment is extra-global depicts that there is a CombinedFragment with the same operator covering the decomposed Lifeline in its Interaction. The full understanding of that (higher level) CombinedFragment must be acquired through combining the operands of the decompositions operand by operand.

Notation

PartDecomposition is designated by a referencing clause in the head of the Lifeline as can be seen in the notation section of "Lifeline (from BasicInteractions, Fragments)" .  See also Figure 340.

Extraglobal CombinedFragments have their rectangular frame go outside the bounderies of the decomposition Interaction.

Style Guidelines

The name of an Interaction that are involved in decomposition would benefit from including in the name, the name of the type of the Part being decomposed and the name of the Interaction originating the decomposition. This is shown in Figure 340 where the decomposition is called AC_UserAccess where `AC' refers to ACSystem which is the type of the Lifeline and UserAccess is the name of the Interaction where the decomposed lifeline is contained.


In Figure 340 we see how ACSystem within UserAccess is to be decomposed to AC_UserAccess which is an Interaction owned by class ACSystem.


In Figure 341 we see that AC_UserAccess has global constructs that match the constructs of UserAccess covering ACSystem.

In particular we notice the "extra global interaction group" that goes beyond the frame of the Interaction. This construct corresponds to a CombinedFragment of UserAccess. However, we want to indicate that the operands of extra global interaction groups are combined one-to-one with similar extra global interaction groups of other decompositions of the same original CombinedFragment.

As a notational shorthand, decompositions can also be shown "inline". In Figure 341 we see that the inner ConnectableElements of :AccessPoint (p1 and p2) are represented by Lifelines already on this level.

Rationale

Not applicable.

Changes from UML 1.x

PartDecomposition did not appear in UML 1.x.

StateInvariant (from BasicInteractions)

A StateInvariant is a constraint on the state of a Lifeline. In this case we mean by "state" also the values of eventual attributes of the Lifeline.

A StateInvariant is an InteractionFragment and it is placed on a Lifeline.

Associations
Semantics

The Constraint is assumed to be evaluated during runtime. The Constraint is evaluated immediately prior to the execution of the next EventOccurrence such that all actions that are not explicitly modeled have been executed. If the Constraint is true the trace is a valid trace; if the Constraint is false the trace is an invalid trace. In other words all traces that has a StateInvariant with a false Constraint is considered invalid.

Notation

The possible associated Constraint is shown as text in curly brackets on the lifeline.

See example in Figure 345.

Presentation Options

A StateInvariant can optionally be shown as a Note associated with an EventOccurrence.

State symbols may also be used to describe a Constraint. The State symbol represents the equivalent of a constraint that checks the state of the classifierBehavior of the enclosing Classifier. Since States may be hierarchical and orthogonal, the following syntax can be used for the state name:

<state-info>::= <region} {,<region> }*
<region>::= <trivial region> | <region-name> {::<state>}?
<trivial region>::= <state>
<state>::= <state-name> {::<region-list>}?
<region-list>::= <region> | ( <state-info> )

The regions represent the orthogonal regions of states. The identifier need only define the state partially. The value of the constraint is true if the specified state information is true.

The example in Figure 345 also shows this presentation option.

Stop (from BasicInteractions)

A Stop is an EventOccurrence that defines the termination of the instance specified by the Lifeline on which the Stop occurs.

Associations

No more associations

Constraints

[1] No other EventOccurrences may appear below a Stop on a given Lifeline in an InteractionOperand.

Semantics

It is assumed that a Stop implies that the instance described by this Lifeline will terminate.
The trace representing its semantics only contains a "stop" EventOccurrence.

Notation

The Stop is depicted by a cross in the form of an X at the bottom of a Lifeline.

See example in Figure 333.