Previous UML Classes Table of Contents UML Packages Next

14.3.13 Interaction

BasicInteraction, Fragments



    Behavior (from BasicBehaviors ) on page 447


    InteractionFragment (from BasicInteractions , Fragments ) on page 505


   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.


Issue 8338 -remove erroneous ‘event’ entry


   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.


   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.


Figure 14.16 - An example of an Interaction in the form of a Sequence Diagram

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.