Previous UML Classes Table of Contents UML Packages Next

14.3.3 CombinedFragment




    InteractionFragment (from BasicInteractions , Fragments ) on page 505


   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 CombinedFragment s the user will be able to describe a number of traces in a compact and concise manner.

   CombinedFragment is a specialization of InteractionFragment .


Issue 8341 - replace ‘InteractionOperator’ with ‘InteractionOperatorKind ’ 9191 - add default value

   • interactionOperator : InteractionOperatorKind Specifies the operation that defines the semantics of this combination of InteractionFragments . Default value is seq.


   • cfragmentGate : Gate [*] Specifies the gates that form the interface between this CombinedFragment and its surroundings.

Issue 8324 - add subsets constraint

   • operand: InteractionOperand [1..*] The set of operands of the combined fragment. {Subsets Element::ownedElement}


   [1] If the interactionOperator is opt, loop, break, 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.

   [3] If the interactionOperator is break, the corresponding InteractionOperand must cover all Lifeline s within the enclosing InteractionFragment .

   [4] The interaction operators ‘consider’ and ‘ignore’ can only be used for the CombineIgnoreFragment subtype of CombinedFragment .

   ((interactionOperator = #consider) or (interactionOperator = #ignore)) implies oclsisTypeOf(CombineIgnoreFragment)


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


   The interactionOperator alt designates that the CombinedFragment represents a choice of behavior. At most one of the operands will be chosen. The chosen operand 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 .

   If none of the operands has a guard that evaluates to true, none of the operands are executed and the remainder of the enclosing InteractionFragment is executed.


   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.


   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 . A break operator with a guard is chosen when the guard is true and the rest of the enclosing Interaction Fragment is ignored. When the guard of the break operand is false, the break operand is ignored and the rest of the enclosing InteractionFragment is chosen. The choice between a break operand without a guard and the rest of the enclosing InteractionFragment is done non-deterministically.

   A CombinedFragment with interactionOperator break should cover all Lifeline s of the enclosing InteractionFragment .


Issue 8349 - replace ‘EventOccurrence’ by ‘OccurrenceSpecification’

   The interactionOperator par designates that the CombinedFragment represents a parallel merge between the behaviors of the operands. The OccurrenceSpecifications 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 OccurrenceSpecifications of the operands may be interleaved without obstructing the order of the OccurrenceSpecifications 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:

Issue 8349 - replace ‘EventOccurrence’ by ‘OccurrenceSpecification’

   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

Issue 8349 - replace ‘EventOccurrence’ by ‘OccurrenceSpecification’

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


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

   The set of traces that defined a CombinedFragment with interactionOperator negative 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 OccurrenceSpecifications (on those Lifeline s 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 CombinedFragment s may imply that some OccurrenceSpecifications may interleave into the region, such as with par-operator, this is prevented by defining a region.

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

Figure 14.10 - Critical Region

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

   Ignore / Consider

    See the semantics of 14.3.4, ConsiderIgnoreFragment (from Fragments ), on page 493.


   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 14.24.


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

Issue 8509 - capitalize ‘boolean’

   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 represents a recursive application of the seq operator where the loop operand is sequenced after the result of earlier iterations.

   The Semantics of Gate s (see also Gate (from Fragments ) on page 500)

   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.


   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 CombinedFragment s. This means that sd strict in the pentagon descriptor is the same as two CombinedFragment s 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.


   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 OccurrenceSpecification 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

    See the notation for ConsiderIgnoreFragment (from Fragments ) on page 493.


   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 Options 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 14.12 .


Issue 6463 -Clarifying figure and coding of special messages.

Figure 14.11 - CombinedFragment

   Changes from previous UML

   This concept was not included in UML 1.x.