*Description
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 .
Attributes
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.
Associations
• 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}
Constraints
[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)
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 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.
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 . 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 .
Parallel
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’
1. The ordering of OccurrenceSpecifications within each of the operands are maintained in the result.
2. OccurrenceSpecifications on different lifelines from different operands may come in any order.
3. OccurrenceSpecifications on the same lifeline from different operands are ordered such that anOccurrenceSpecification 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
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 .
Negative
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.
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.
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 14.24.
Loop
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.
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 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.
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 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.
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 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
.
Examples
Issue 6463 -Clarifying figure and coding of special messages.
Changes from previous UML
This concept was not included in UML 1.x.