*Description
An interaction is a unit of behavior that focuses on the observable exchange of information between ConnectableElement s.
An Interaction is a specialization of InteractionFragment and of Behavior.
Associations
• formalGate : Gate [*] Specifies the gates that form the message interface between this Interaction and any InteractionUse s that reference it.
• lifeline: LifeLine[0..*] Specifies the participants in this Interaction.
Issue 8338 -remove erroneous ‘event’ entry
• message:Message[*] The Messages contained in this Interaction.
• fragment:InteractionFragment [*] The ordered set of fragments in the Interaction.
• action:Action[*] Actions owned by the Interaction. See ActionExecutionSpecification (from BasicInteractions ) on page 486.
Semantics
Interactions are units of behavior of an enclosing Classifier. Interactions focus on the passing of information with Messages
between the ConnectableElement s 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 event occurrences, each of which is described by an OccurrenceSpecification in a model. 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 on page 489.
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 InteractionUse s 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 need 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 CombinedFragment s 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 InvocationOccurrence in the Execution model corresponds with an (event) Occurrence in a trace. Occurrences are modeled
in an Interaction by OccurrenceSpecifications. 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 OccurrenceSpecification. An occurrence in Interactions is normally interpreted to take zero time. Duration
is always between occurrences.
Issue 8338 - replace ‘is’ with ‘are’
Likewise a ReceiveOccurrence in the Execution model is modeled by an OccurrenceSpecification. Similarly the detailed actions
following immediately from this reception are often omitted in Interactions, but may also be described explicitly with a Behavior
associated with that OccurrenceSpecification.
A Request in the Execution model is modeled by the Message in Interactions.
An Execution in the Execution model is modeled by an ExecutionSpecification in Interactions. An Execution is defined in the
trace by two Occurrences, one at the start and one at the end. This corresponds to the StartOccurrence and the CompletionOccurrence
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 Lifeline s through a lifeline-clause as shown in Figure 14.28. The list
of lifelines is simply a listing of the Lifeline s 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 at other places in the diagram.
Please refer to Section 14.4 to see examples of notation
for Interactions.
Examples
Issue 8349 -replace ‘EventOccurrence’ by ‘OccurrenceSpecification’
The example in Figure 14.16 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 OccurrenceSpecifications. 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 attribute
PIN of UserAccepted is declared near the diagram top. It could have been declared in a Note somewhere else in the diagram.
Changes from previous UML
Interactions are now contained within Classifiers and not only within Collaborations . Their participants are modeled by Lifeline s
instead of ClassifierRoles.