Interaction Diagrams

An interaction describes an array of messages which are exchanged by a selected number of participants in a chronologically-limited circumstance.

UML 2.0 specifies three different diagrams for the illustration of interactions:

  • Sequence Diagrams emphasize the order of message Exchange
  • Communication Diagrams emphasize the relationships among participants
  • Timing Diagrams emphasize the state change of participants against time and the exchanged messages

Sequence Diagram

A Sequence Diagram is primarily concerned with the chronological progression of messages. The messaging sequence corresponds to its horizontal position in the diagram. When an object is created, and when and to what object information is sent, are all determined here.

The participating objects are represented by a rectangle and a dashed vertical line. Both together are called a Lifeline. Messages are shown using arrows between the Lifelines. Time progresses from top to bottom. The chronological progress of messages is thereby highlighted.

The sequence diagram in the following illustration shows an interaction among three objects. It is important that the entire diagram represents an interaction, and that an interaction is not only a single message exchange.

Fig. 53: Simple example of a sequence diagram

In the heading of the Lifeline is the (optional) element name with the associated class in the usual declaration notation: name : type.


When messages are exchanged between Lifelines, a Behavior must also be implemented in the associated elements. This is shown by the elongated rectangle on the Lifeline. These rectangles represent the so-called ExecutionOccurence. Start and End of ExecutionOccurence are defined via the so-called Event Occurrence. Put more simply, the sending and receiving of messages determines the start and end of the ExecutionOccurence.

Message Types

The transfer of a message is noted using arrows. Labeling of messages is carried out using the names of the corresponding operations. UML recognizes various types of messages which are demonstrated using various kinds of arrow notation. In the following illustration, the various message types and corresponding notation forms are shown.

  • Synchronous Messages are represented by filled arrowheads. Synchronous means that the caller waits until the called behavior has ended. The Reply Message to a synchronous call is represented by a dashed line and open arrow point.
  • Asynchronous Messages have an open arrow point. Asynchronous means that the caller does not wait, but rather proceeds immediately after the call. There is accordingly no answer arrow to asynchronous calls.
  • Lost Messages have an open arrow point in the direction of a filled circle. The circle is not linked to a Lifeline. When a message is lost the sender is recognized, but not the receiver.
    • Found Messages have an open arrow point. The line emanates from a filled circle. The circle is not linked to a Lifeline. When a message is found the receiver is recognized, but not the sender.
  • A message which creates a new Element is represented by a line and open arrow point. The Lifeline which belongs to the Element starts first on this place in the diagram; e.g., the arrow points to the Lifeline header.

Fig. 54: Notation Forms of the various Message Types

Repeated message sending is modeled by adding the * symbol, in which case the message has the * symbol placed in front.

The message is noted on the message arrow with the following syntax:

[attribute =] name [(arguments)] [: return value]



  • "attribute" can be a local variable of the interaction, or an Element of a Lifeline. The attribute allocation is only used in synchronous messages with return value.
  • "name" is the name of the message to be called, or the name of the signal to be sent. The sending of a signal is always as asynchronous character.
  • "arguments" is a comma-separated list of parameter values transferred to the message.

If an object is created via the setting of a message (e.g. by calling the method "new"), then the Lifeline of this object begins at this position. The destruction of an object is represented by a cross on the Lifeline.


The following table contains the sequence diagram symbols.



System Border

The System Border isolates the concerned part of the program from the rest of the program. It usually serves as the start point of the triggering method call. Program flow is not always triggered by an object outside of the concerned area, so that in this case no system limit must be set.


An object is shown by a rectangle containing the name. Underlining of the name may be omitted so that no confusion with the class name can occur. Classes are not displayed in this diagram. Objects are shown along the upper sheet edge.


Every object is on a vertical line - the Lifeline. An object’s lifeline grows in the direction of the lower sheet edge. For objects which already exist at the start of the program section, the object symbols are drawn on the upper sheet edge. For objects which are re-created within the program section, the symbol is drawn at the level of the method call in the course of which the object was created.

Object Activity

If an object is involved in a method call, it is active. The Lifeline thickens. If an object calls its own method, the Lifeline thickens again. These activities are not always drawn.

Method Call

When an object calls a method of another object, this is symbolized by a continuous arrow which points to the object from which the method was called. The method name is placed on this symbol. This name can be added to the parameters list in parentheses.

Method Return

In principle, only the method calls are shown in the sequence diagram. Should you nevertheless wish to plot method returns, this can be done with an arrow and a dashed line.

Object Creation

If a method creates an object, the method's arrow ends on the object's rectangular symbol. The Lifeline begins at this symbol.

Object Destruction

If an object is destroyed when a method is called, the object's Lifeline ends with a cross below the method call symbol.


A theatre's ticket system allows tickets to be sold out of the seating plan on an Internet website. The seating plan manages the seats of a given event.

When a seat is selected by a user, the concerned object :seat calls the "buy" method of the ":order" object and transfers a reference to itself in the parameter. The order class object calls the method "isFree(seat)" of the Seating Plan class to check whether the seat transferred into the parameter is free. If the seat is still free, the Seating Plan object calls its own method, "reserve". The seat is thereby reserved for the time being.

After this has taken place, the invoice for the seat is created. The seating plan object then calls the "book" method with the chosen seat as parameter. The "book" method belongs to the object :order. This represents a list of the invoice line items - which is not modeled here. After the invoice line items have been compiled by the object :sales, it calls the "createInvoice" method of the object :order. To notify the Internet ticket system user of the success of his purchase, the Order object calls the method "confirmed" of the class Seat. The visitor confirms the order, and the method "confirmed" returns with the value "true". The order is completed.

Fig. 55: Example of a Sequence Diagram

Communication Diagram

The Communication Diagram corresponds to the UML 1.x Collaboration Diagram. It has been renamed to avoid the confusion caused by the term "Collaboration", as UML also has the modeling element "Collaboration" which has nothing to do with a Collaboration (Communication) Diagram.

The Communication Diagram is a different approach to displaying the circumstances of a sequence diagram. This diagram gives special attention to the cooperation of the interconnected objects. Selected messages are used with which the chronological communication sequence between the objects takes place. It thereby compiles the conclusions of the sequence diagram in a more compact form.

In the following illustration, one can clearly see that the communication diagram emphasizes the relationships between the involved parties, and not the chronological progression of message exchange like the sequence diagram.

Fig. 56: Example of the "Identify Authorization" Communication Diagram

Graphical representation is a rectangle which contains the object name and the respective class. A colon separates both names. The objects are linked by association lines. A small arrow shows each message direction from sender to receiver. When arguments are transferred with the message, these are executed. Possible return values can also be output in the form:

answer := Messagename (list of Parameters)

In order to model the chronological sequence, the messages are given numbers. One message can trigger further messages. These receive sub-numbers of the triggering message (e.g. 1.2).

If a message is repeatedly triggered, this iteration can be modeled using a * character in front of the message name.

Objects which are created within the illustrated scenario can be indicated using the stereotype new. Objects which are destroyed within the illustrated scenario are indicated using the stereotype destroy. Objects which are created and destroyed within the scenario receive the stereotype transient.


The following table contains the Communication Diagram symbols.





This rectangle is the symbol of an object and contains the object name. No confusion with classes may occur, so the name must not be underlined.


When two objects communicate with one another via a method call, this link is shown with a solid line connecting both objects.

Communication Direction

In addition to the connecting line, after the method name an arrow shows to which object the method belongs. The arrow points to this object.


This line is labeled with the method name and the parameter list. Numbers placed in front of the method name indicate the chronological order of method calls, separated by a colon. You can enter the method numbers in a condition which are, as a precondition, already being processed. The * symbol in front of the method name indicates a repeat of that method. The condition for repetition can be entered after the * symbol.


This example models the purchase of a ticket via the Internet. The Internet customer selects a seat on a theatre's website, thereby calling the "select" method. The interaction is started. The object :seat calls the "buy" method of the Order object and transfers a reference to itself in the parameter. The :order object calls the method isFree of the object :seating plan. On the one hand, this method calls the "reserve" method, and on the other hand the "book" method. They therefore differ only in their sub number. The Seating Plan object calls the method "book" of the :sale object. This object calls the method "createInvoice" of the object Order and transfers the invoice line item of the booked seat. After the invoice has been created by the object :order, the Internet customer is informed of the successful booking, whereby the method "confirmed" is called which queries and returns the customer's confirmation.

This example models the purchase of a ticket via the Internet. The Internet customer selects a seat on a theatre's website, thereby calling the "select" method. The interaction is started. The object :seat calls the "buy" method of the Order object and transfers a reference to itself in the parameter. The :order object calls the method isFree of the object :seating plan. On the one hand, this method calls the "reserve" method, and on the other hand the "book" method. They therefore differ only in their sub number. The Seating Plan object calls the method "book" of the :sale object. This object calls the method "createInvoice" of the object Order and transfers the invoice line item of the booked seat. After the invoice has been created by the object :order, the Internet customer is informed of the successful booking, whereby the method "confirmed" is called which queries and returns the customer's confirmation.

Sequence Diagrams vs. Communication Diagrams

Sequence and Communication Diagrams are very similar and can also be merged into several UML Tools. However, due to the greater expressiveness of sequence diagrams in UML 2.1 it is no longer possible to substitute every sequence diagram with a communication diagram. The focus of the sequence diagram is on the chronological aspect, while for the communication diagram focus is on the relationships between the objects. The greatest advantage of the sequence diagram - and at the same time greatest disadvantage of the communication diagram - is the clearly visible chronological sequence which can principally be visualized in communication diagrams with a numbering scheme, but much less visibly. In this case the order of execution must not be set right away, making the creation of a sequence diagram somewhat tricky at times. On the other hand, in a comprehensive communication diagram the order is not easily readable. The reader must use the Search function to find out whether 1.1 2, 1.2 or even 1.1.1 follows.

Interaction Overview Diagram

The Interaction Overview Diagram is new in UML 2.0/2.1. It merely represents a mix of activity and sequence diagrams, whereby activity blocks can be mixed into a sequence diagram, and vice versa. Since it contains no other innovations, no further details will be explored here.

The following example shows the "Execute Bank Transfer" process, whereby the main diagram here is an activity diagram and an action (save order) is more precisely described using a sequence diagram.

Component Diagram

Component diagrams show the interaction of component relationships. A component is an executable and exchangeable software unit with defined interfaces and individual identities. A component is, like a class, instanceable and capsules complex functionality.

The component Component2 provides functionality via its interface. Component1 communicates over the interface Interface1 provided by Component2 and utilises its functionality.


The following table contains the component diagram symbols.




The component symbol is an arrangement of three rectangles. Two rectangles are drawn on the left side of the third, larger rectangle - where the name of the component is located. Components completely fulfill the tasks of an autonomous area for which it was developed.


A component can provide an interface. This is where administered access to component functionality takes place. Interfaces make these elements exchangeable.

An interface is shown with a circle. This circle is linked to the class, the package or the component by a solid line. The name of the interface is given next to the symbol.


This arrow on a dashed line symbolizes access to the interface. The arrow points to the interface symbol circle. It can also point directly to a component when access does not take place via the interface.



In this example, four components are linked to an application to show database data in a window. The database access component is responsible for the establishment, management and interruption of database access. It provides methods via an interface over which the data container component can request data from the database.

The data container component manages the requested data sets. At the same time, a transaction is started for each data transfer via the transfer management component. The component for graphical representation calls the data sets via the data container component interface and shows these on the screen.

Should the user alter the data, the component transfers these changes to the data container component. The altered data are written by these in the database via the connection component and the new data are verified over the Data Transfer component, then the started transaction ends.

Deployment Diagram

Dependencies between nodes, the nodes themselves, their contents and communication are shown in this diagram. A node is a physical unit which possesses storage capacity and computing power (such as a PC) on which further components are run. These nodes are drawn as blocks. Components or processes can be drawn within these blocks. Images which graphically represent these nodes may also be used instead of blocks. Distribution diagrams show which components and objects run on which nodes (computers, processes), i.e. how these are configured and which communication relationships exist.


The following table contains the Deployment Diagram symbols.




A Node is represented by a block. The label placed within the block contains the name of the node, e.g. the name of a computer, a client or a process name.


If an application is carried out in a node's memory storage, this application is modeled as a node instance. To differentiate with the node symbol, the label within the block is underlined. This symbol is inserted into the symbol for the node on which the sub-process is running.


A Component is in scope smaller than a subsystem but assumes application tasks for a specified application range. The Component symbol is inserted into the symbol of the node on which the component is installed.

Component Iinstance

Component Instance is a general term for specific objects, the classes of which belong to the component's data structure and are instanced by it. This symbol does not differ from the component symbol. Differentiation to the component symbol is achieved in that the name of the instance is underlined. The symbol is inserted into the component symbol's instance which it represents.


Relationships between nodes are shown with a solid line which links the nodes.


A cinema's ticket data can be accessed via a ticketing system using various applications. The data are on a central server which is networked with other PC's and connected to the Internet. A component for the administration of the database is installed on the server. The database server Interbase is set up on this server.

  • Box office sales are processed via a PC in the box office area. In order that this PC can access the data quickly enough, a client application is developed which is especially adapted to the requirements of box office sales.
  • The system administrator has a PC for its tasks, e.g. in bookkeeping. He also has a client application which enables him to create and evaluate events.
  • The pre-sales department is driven with its own client application which is connected to the server via the Internet.
  • The Internet customer calls up data from the ticket system from a PC. A ticket system client application tailored to the needs of this customer is required for this procedure.

Timing Diagram

The Timing diagram is primarily implemented in hardware-oriented programming or in chronologically-critical organization projects to analyze processes for optimal flow using a time line.

The following illustration shows a time diagram. Here, emphasis is placed on the state of those involved with respect to a timeline.

Composite Structure Diagram

The internal structure of a class can be described with the Composition Structure Diagram. This diagram is new in UML 2.0/2.1. At first glance, the diagram can be easily mistaken for a communication diagram. The following illustrations show a composition structure diagram and an associated class diagram with compositions. The assertions of both diagrams are equal.

Object Diagram

The Object diagram holds a certain similarity to the class diagram but with the decisive difference that, here, only instances and no classes are displayed. It shows a particular detail of the program during runtime. The individual objects are shown, along with the links and also the multiplicities. For example, this diagram type is implemented during readjustment of errors in the running system. When a particular software behavior occurs under specific conditions, this can be described using the Object diagram by showing the relevant attributes for this circumstance and their values in the objects.

The following example shows a class diagram to the left and the corresponding object diagram to the right.


Logo SparxSystems