UML - Sequence Diagram

Inter-object behaviour: interactions between objects.

Interaction: how data is exchanged between interaction partners.

Interaction partners: - Human (lectures, administrator, …) - Non-human (sever, printer, executable software, …)

Examples of interactions:

• Conversation between persons.
• Message exchange between humans and a software system.
• Communication protocols.
• Sequence of method calls in a program.

Interaction Diagrams §

---

Used to:

1. Specify interactions.
2. Model concrete scenarios.
3. Describe communication sequences at different levels of detail.

They show:

• System’s interaction with its environment.
• Interaction between system parts in order to show how a specific use case can be implemented.
• Interprocess communication in which the partners involved must observe certain protocols.
• Communication at class level (operation calls, inter-object behaviour).

Interaction Partners §

---

Depicted as lifelines.

Head of the lifeline:

• roleName:Class
• Roles are a more general concept than objets.
• Objects can take on different roles over its lifetime.

Body of the lifeline:

• Vertical, dashed line.
• Lifetime of the object associated with it.

Sequence Diagram §

---

Interaction = sequence of event specifications.

• Horizontal axis: involved interaction partners.
• Vertical axis: chronological order of the interaction.

Exchanging Messages §

---

Interaction: sequence of events.

Message is defined via send event and receive event.

Execution specification:

• Continuous bar.
• Used to visualise when an interaction partner executes some behaviour.

Order of messages:

Messages §

---

Synchronous message:

• Filled arrow.
• Sender waits for a response before continuing.
• Syntax of message name: msg(par1, par2)

Asynchronous message:

• Normal arrow.
• Sender continues without waiting for a response message.
• Syntax: msg(par1, par2)

Response message;

• Dashed lines, normal arrow.
• May be omitted if content and location are obvious.
• Syntax: att=msg(par1, par2):val
  • att: return value can optionally be assigned to a variable.
  • msg: name of the message.
  • val: return value.

Found message: sender of a message is unknown or not relevant. Lost message: receiver is unknown or not relevant.

Time-consuming message:

• Message with duration.
• Usually messages are assumed to be transmitted without any loss of time.
• Expresses that time elapses between the sending and the receipt of a message.

Objects §

---

Object creation:

• Arrowhead points to the head of the lifeline of the object to be created.
• Keyword: new.

Object destruction:

• Object is deleted.
• Large cross at the end of the lifeline.

Combined Fragments §

---

It models various control structures and has 12 predefined types of operators.

Types of Combined Fragments §

---

Alt Fragment §

• To model alternative sequences, similar to switch statement.

• Guards: used to select one path to be executed.

  • Modelled in square brackets.
  • default: true
  • predefined: [else]
  • Have to be disjoint to avoid indeterministic behaviour.

• Multiple operands.

Opt Fragment §

• To model an optional sequence.
• Execution at runtime is dependent on the guard.
• Exactly one operand.
• Similar to if statement without the else branch.
• Equivalent to alt fragment with two operands, one of which is empty.

Loop Fragment §

• To express that a sequence is to be executed repeatedly.
• Exactly one operand.
• loop followed by the min/max number of iterations.
  • default: (*) .. no upper limit.

Guard:

• Evaluated as soon as the minimum number of iterations has taken place.
• Checked for each iteration within the (min, max) limits.
• If the guard evaluates to false, the execution of the loop is terminated.

Break Fragment §

• Simple form of exception handling.
• Exactly one operand with a guard.
• If the guard is true:
  • Interactions within this operand are executed.
  • Remaining operations of the surrounding fragment are omitted.
  • Interaction continues in the next higher level fragment.
  • Different behaviour than opt fragment.

Note that D is not executed if break is executed.

Loop and Break Fragment - Example §

Seq Fragment §

• Default order of events.
• Weak sequencing:
  1. Ordering of events within each of the operands is maintained in the result.
  2. Events on different lifelines from different operands may come in any order.
  3. Events on the same lifeline from different operands are ordered such that an event of the first operand comes before that of the second operand.

Seq Fragment - Example §

Strict Fragment §

• Sequential interaction with order.
• Order of event occurrences on different lifelines between different operands is significant.

Messages in an operand that is higher up on the vertical axis are always exchanged before the messages in an operand that is lower down on the vertical axis.

Strict Fragment - Example §

Par Fragment §

• To set aside chronological order between messages in different operands.
• Execution paths of different operands can be interleaved.
• Restrictions of each operand need to be respected.
• Order of the different operands is irrelevant.
• Concurrency, no true parallelism

Par Fragment - Example §