InteractionOperator
InteractionOperand
CombinedFragment
InteractionOperand
contains InteractionOccurence =
sequence of messages passed
between objects.
Using interaction operands within a combined fragment
An interaction operand represents an interaction with an optional guard
expression. The interaction operand is executed only if the guard expression
tests true at runtime. The guard is placed at the very start of the interaction.
The values tested in the guard condition may refer only to values owned by
the lifeline at which the first event occurrence of the interaction is located. In
other words, the object that starts the interaction requires all the information
necessary to make the decision about whether to proceed. The absence of
any guard condition means that the interaction is always executed.
A combined fragment separates the contained interaction operands with a
dashed horizontal line between each operand within the frame of the
combined fragment. When the combined fragment contains only one operand
the dashed line is unnecessary.
Interaction operators
The InteractionOperator is modeled as text in a small compartment in the
upper left corner of the CombinedFragment frame. The set of valid interaction
operators is defined in an enumeration called (oddly enough)
InteractionOperator. The following section provides descriptions for the set of
valid interaction operators, and brief explanations of their use.
Alternatives
The alt (alternatives) interaction operator identifies a set of behaviors from
which the interaction can choose based on specified criteria. Only one of the
offered alternatives will execute on any one pass through the interaction.
However, as is true of any operand, the selected operand in the alt structure
executes only if the guard condition tests true. If there is no guard, the
operand always executes when selected. The else clause of the alt
combined fragment executes whenever none of the other options is selected.
The previuos figure provides an example in which a combined fragment
resides within the example interaction. The alt combined fragment offers one
option, and an else clause. If the guard [x>0] tests true, the first fragment
will execute. If it tests false, the interaction specified by the
else fragment will execute.
An alt combined fragment may offer any number of alternatives.
Option
The opt (option) interaction operator represents a behavior that may or may
not be used as part of the interaction. To be used, the guard condition must
be satisfied. If the guard condition fails, the behavior is simply skipped. The
model for an opt combined fragment looks like an alt that offers only one
interaction.
Break
The break interaction operator provides a mechanism similar to the break
syntax in many programming languages. In the course of executing an
interaction, if the guard of the break is satisfied, then the containing interaction
abandons its normal execution and instead performs the clause specified
by the break fragment.
Parallel
The par (parallel) interaction operator supports parallel execution of a set of
interaction fragments. The integrity of each interaction fragment is preserved
while allowing the exact execution of the events within each interaction
fragment to be interwoven in any way supported by the processing
environment. Next figure is an example of a combined fragment with three
parallel interactions. All three may execute at the same time, and the
individual events within each interaction fragment may execute in any order
within the constraints of the individual interaction fragments without regard for
other events on the same lifelines.
Parallel combined fragments.
Weak Sequence
The seq (weak sequence) interaction operator forces the interactions to follow
a certain order. The order is based on the placement of the interaction
fragments within the combined fragment in the same way that events
messages are ordered by their placement on the vertical lifeline. If two events
occur on the same lifeline, the event on the uppermost interaction executes
first. The complete rules for maintaining the order of execution are as follows
(UML 2.0):
1. The ordering of event occurrences within each of the operands is
maintained in the result.
2. Event occurrences on different lifelines from different operands may come
in any order.
3. Event occurrences on the same lifeline from different operands are ordered
such that an event occurrence of the first operand comes before that of the
second operand.
Contrast this description to the strict interaction operator described next.
Strict Sequence
The strict (strict sequence) interaction operator explicitly defines the order
of execution for a set of interaction fragments. The ordering is limited to the
interactions on the first level of a nested interaction fragment, so no evaluation
is made of events within any nested interaction fragments. The effect of
strict is to force the completion of one interaction before proceeding to the
next interaction.
Contrast this with seq, which allows partial parallel execution, but forces
sequencing of the execution of events on the same lifeline from different
interactions.
Negative
The neg (negative) interaction operator is used to identify interactions that
should not be allowed to happen. That is, these interactions are explicitly
described as invalid. The neg operator can provide a convenient shorthand
when any number of options is valid but only one or a small number of options
are not allowed—it might be easier and less time consuming to identify the
exceptions.
Critical Region
The region (critical region) interaction operator identifies an interaction that
takes precedence over all other interaction fragments within the context of the
combined fragment. In the following figure all the interaction fragments may
execute in any order, unless the critical region is invoked, and then it must
execute before any of the other fragments may execute. So if the operation
c() is invoked, it will run to completion before any new calls to a() or b() are
allowed to execute.
Modeling a critical region.
Ignore/consider
The ignore interaction operator explicitly identifies messages to which the
interaction fragment should not respond. The consider interaction operator
explicitly identifies messages that should be handled, and is the equivalent to
labeling every other message to be ignored. The two operators enhance ease
of modeling in that they enable the modeler to focus on the most relevant
behavior without specifying every exception. The syntax for the
ignore/consider operator is as follows:
(ignore | consider ) { <message name> [ ,<message name>]* }
Both operators use a comma-separated list of messages. For example:
ignore {a, b}: Although messages a and b might be directed at the
objects in this interaction, they are considered insignificant and so do not
appear in the body of the interaction fragment.
consider {c, d}: Only the messages c and d are considered significant.
No other messages are addressed by the interaction fragment, even if those
messages are directed at objects within the interaction fragment.
The ignore and consider operations are usually combined with other
operations.
Modeling the interaction operators ignore, consider, and assert.
Assertion
The assert (assertion) interaction operator identifies an operand as the only
valid continuation of events in an interaction fragment. Alternative scenarios
often are modeled using other Sequence diagrams. Using an assertion tells
those reading the model that what they see is the only valid sequence
of events. There is no other place to look.
Loop
The loop interaction operator indicates that the interaction fragment will be
executed repeatedly. The number of times it is executed is determined by the
minint and maxint parameters of the operator.
The syntax of the loop operator is:
loop(minint, maxint)
where maxint may also be infinity (*).
Once the minimum number of iterations has been satisfied, a Boolean
expression is tested on each pass.
When the Boolean expression tests false, the loop ends.
Using the syntax loop (integer) is a convention used for multiplicity
throughout the UML to mean that the minimum and maximum values are the
same.
Using the syntax loop means the loop has no upper bound, or the same as
zero to infinity. The only way out of the loop is for the Boolean expression to
test false.