This presentation is about a lecture I gave within the "Software Modeling" course of the Computer Science bachelor program, of the Vrije Universiteit Amsterdam. http://www.ivanomalavolta.com

1. Software and Services research group (S2)
Department of Computer Science, Faculty of Sciences
Vrije Universiteit Amsterdam
VRIJE
UNIVERSITEIT
AMSTERDAM
Modeling objects interaction
via UML sequence diagrams
Software modeling (401016) – 2016/2017
Ivano Malavolta
i.malavolta@vu.nl

2. VRIJE
UNIVERSITEIT
AMSTERDAM
Examples of questions in the final exam (1)
2

3. VRIJE
UNIVERSITEIT
AMSTERDAM
Examples of questions in the final exam (2)
3

4. VRIJE
UNIVERSITEIT
AMSTERDAM
Examples of questions in the final exam (3)
4

5. VRIJE
UNIVERSITEIT
AMSTERDAM
Examples of questions in the final exam (4)
5

6. VRIJE
UNIVERSITEIT
AMSTERDAM
Roadmap
§ Introduction
§ Basics
§ Interactions and interaction partners
§ Messages
§ Combined fragments
§ Branches and loops
§ Concurrency and order
§ Filters and assertions
§ Further language elements
6

7. VRIJE
UNIVERSITEIT
AMSTERDAM
Introduction
§Interaction
§ Specifies how messages and data are exchanged between objects
§Interaction partners
§ Human (lecturer, administrator, …)
§ Non-human (server, 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
§ …
7
MAIN GOAL
To model interactions between objects

8. VRIJE
UNIVERSITEIT
AMSTERDAM
Sequence Diagram
§ Two-dimensional diagram
§ Horizontal axis: involved interaction partners
§ Vertical axis: chronological order of the interaction
§ Interaction = sequence of event specifications
8

9. VRIJE
UNIVERSITEIT
AMSTERDAM
Interaction Partners
§ Interaction partners are depicted as lifelines
§ Head of the lifeline
§ Rectangle that contains the expression object:Class
§ Body of the lifeline
§ Vertical dashed line
§ Represents the lifetime of the object associated with it
Head of the lifeline
Body of the Lifeline
9

10. VRIJE
UNIVERSITEIT
AMSTERDAM
Exchanging Messages (1/2)
§ Interaction: sequence of events
§ Message is defined via send event and receive event
§ Execution specification
§ Continuous bar
§ Used to visualize when an interaction partner executes some
behavior
Send event Receive event
Execution specification
10

11. VRIJE
UNIVERSITEIT
AMSTERDAM
Exchanging Messages (2/2)
3. on different lifelines which exchange messages
2. on different lifelines1. on one lifeline
»Happens before«
11
3 rules about order of messages:

12. VRIJE
UNIVERSITEIT
AMSTERDAM
Messages (1/3)
§ Synchronous message
§ Sender waits until it has received a response message
before continuing
§ Syntax of message name: msg(par1,par2)
§ msg: the name of the message
§ par: parameters separated by commas
§Asynchronous message
§ Sender continues without waiting for a response
message
§ Syntax of message name: msg(par1,par2)
§Response message
§ May be omitted if content and location are obvious
§ Syntax: att = msg(par1,par2):val
§ att: the return value can optionally be assigned to a variable
§ msg: the name of the message
§ par: parameters separated by commas
§ val: return value
12

13. VRIJE
UNIVERSITEIT
AMSTERDAM
Messages (2/3)
§ Object creation
§ Dashed arrow
§ 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
13

14. VRIJE
UNIVERSITEIT
AMSTERDAM
Messages (3/3)
§ Found message
§ Sender unknown or not relevant
§ Lost message
§ Receiver unknown or not relevant
§ Time-consuming message
§ "Message with duration"
§ Usually messages are assumed to be transmitted
without any loss of time
§ Express that time elapses between the sending and
the receipt of a message
14

15. VRIJE
UNIVERSITEIT
AMSTERDAM
Combined fragments
15

16. VRIJE
UNIVERSITEIT
AMSTERDAM
Combined Fragments
§ Model various control structures
§ 12 predefined types of operators
Operand
Operand
Combined Fragment
Operator
Operand
16

17. VRIJE
UNIVERSITEIT
AMSTERDAM
Types of Combined Fragments
Operator Purpose
alt Alternative interaction
opt Optional interaction
loop Repeated interaction
break Exception interaction
seq Weak order
strict Strict order
par Concurrent interaction
critical Atomic interaction
ignore Irrelevant interaction
consider Relevant interaction
assert Asserted interaction
neg Invalid interaction
Branchesand
loops
Concurrencyand
order
Filtersand
assertions
17

18. VRIJE
UNIVERSITEIT
AMSTERDAM
alt Fragment
§ Similar to switch statement in
Java
§ Guards are used to select the
one path to be executed
§ Guards
§ Modeled in square
brackets
§ default: true
§ predefined: [else]
§ Multiple operands
§ Guards have to be disjoint to
avoid indeterministic behavior 18
To model alternative
sequences

19. VRIJE
UNIVERSITEIT
AMSTERDAM
opt Fragment
§Actual execution at
runtime is dependent on
the guard
§ Exactly one operand
§ Similar to if statement
without else branch
19
To model an optional
sequence

20. VRIJE
UNIVERSITEIT
AMSTERDAM
loop Fragment
§ Exactly one operand
§ Minimal/maximal number of iterations
§ (min..max) or (min,max)
§ 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
Notation alternatives:
loop(3,8) = loop(3..8)
loop(8,8) = loop (8)
loop = loop (*) = loop(0,*)
loop is
executed at
least once,
then as long as
a<1 is true
Min
Guard
Max
To model repeated
sequences

21. VRIJE
UNIVERSITEIT
AMSTERDAM
break Fragment
§ Exactly one operand with a guard
§ If the guard is true:
§ Interactions within this operand are executed
§ (b à c)
§ Remaining operations of the surrounding
fragment are omitted
§ (d)
§ Interaction continues in the next higher
level fragment
§ (e)
Not executed if break is executed
To model exception
handling

22. VRIJE
UNIVERSITEIT
AMSTERDAM
loop and break Fragment - Example
22

23. VRIJE
UNIVERSITEIT
AMSTERDAM
Types of Combined Fragments
Operator Purpose
alt Alternative interaction
opt Optional interaction
loop Repeated interaction
break Exception interaction
seq Weak order
strict Strict order
par Concurrent interaction
critical Atomic interaction
ignore Irrelevant interaction
consider Relevant interaction
assert Asserted interaction
neg Invalid interaction
Branchesand
loops
Concurrencyand
order
Filtersand
assertions
23

24. VRIJE
UNIVERSITEIT
AMSTERDAM
seq Fragment
§ Weak sequencing:
1. Events on different lifelines from different operands may come
in any order
2. 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
3. The ordering of events within each of the operands is
maintained in the result
24
The default order of
events

25. VRIJE
UNIVERSITEIT
AMSTERDAM
seq Fragment – Example
25

26. VRIJE
UNIVERSITEIT
AMSTERDAM
strict Fragment
§ 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
26
Fixed sequence of events
across lifelines

27. VRIJE
UNIVERSITEIT
AMSTERDAM
strict Fragment - Example
27

28. VRIJE
UNIVERSITEIT
AMSTERDAM
par Fragment
28
§ Execution paths of different operands can be interleaved
§ Restrictions of each operand need to be respected
§ Order of the different operands is irrelevant
To relax the chronological order between
messages in different operands

29. VRIJE
UNIVERSITEIT
AMSTERDAM
par Fragment - Example
29

30. VRIJE
UNIVERSITEIT
AMSTERDAM
critical Fragment
§ To make sure that certain parts of an interaction are not
interrupted by unexpected events
30
Atomic area

31. VRIJE
UNIVERSITEIT
AMSTERDAM
critical Fragment - Example
31

32. VRIJE
UNIVERSITEIT
AMSTERDAM
Types of Combined Fragments
Operator Purpose
alt Alternative interaction
opt Optional interaction
loop Repeated interaction
break Exception interaction
seq Weak order
strict Strict order
par Concurrent interaction
critical Atomic interaction
ignore Irrelevant interaction
consider Relevant interaction
assert Asserted interaction
neg Invalid interaction
Branchesand
loops
Concurrencyand
order
Filtersand
assertions
32

33. VRIJE
UNIVERSITEIT
AMSTERDAM
ignore Fragment
§ Messages may occur at runtime but have no further significance
§ Exactly one operand
§ Irrelevant messages in curly brackets after the keyword ignore
33
To represent
irrelevant messages

34. VRIJE
UNIVERSITEIT
AMSTERDAM
consider Fragment
§ Exactly one operand, dual to ignore fragment
§ Considered messages in curly brackets after the keyword
consider
34
To represent messages with
particular importance

35. VRIJE
UNIVERSITEIT
AMSTERDAM
ignore vs. consider
35
These are the same

36. VRIJE
UNIVERSITEIT
AMSTERDAM
assert Fragment
§ Deviations that occur in reality but that are not included in the
diagram are not permitted
36
To represent mandatory
interactions

37. VRIJE
UNIVERSITEIT
AMSTERDAM
neg Fragment
§ Describing situations that must not occur
§ Purpose
§ Explicitly highlighting frequently occurring errors
§ Depicting relevant, incorrect sequences
37
To explicitly represent
invalid interactions

38. VRIJE
UNIVERSITEIT
AMSTERDAM
Further language elements
38

39. VRIJE
UNIVERSITEIT
AMSTERDAM
Time Constraints
§Types
§ Point in time for event
occurrence
§ Relative: e.g., after(5sec)
§ Absolute: e.g., at(12.00)
§ Time period between two events
§ {lower..upper}
§ E.g., {12.00..13.00}
§Predefined actions
§ now: current time
§ Can be assigned to an attribute
and then used in a time constraint
§ Duration: calculation of the
duration of a message
transmission
39

40. VRIJE
UNIVERSITEIT
AMSTERDAM
Interaction Reference
§ Integrates one sequence diagram in another sequence
diagram
40
Definition
Usage

41. VRIJE
UNIVERSITEIT
AMSTERDAM
Gate
§ Allows you to send and receive messages beyond the
boundaries of the interaction fragment
41

42. VRIJE
UNIVERSITEIT
AMSTERDAM
Local Attributes and Parameters
§ Every sequence diagram is enclosed by a rectangular frame
with a small pentagon in the upper left corner
§ Keyword sd, name of the sequence diagram, parameters
(optional)
§ Example:
Option 1: Option 2:
void func (int par1, int par2) {
int x = 0;
String y = "Test";
...
}
Parameter
Local
attributes
42

43. VRIJE
UNIVERSITEIT
AMSTERDAM
State Invariant
§ Asserts that a certain condition must be fulfilled at a certain
time
§ Evaluation before the subsequent event occurs
§ If the state invariant is not true, either the model or the
implementation is incorrect
§ Three alternative notations:
43
Useful for linking your state
machines and sequence
diagrams

44. VRIJE
UNIVERSITEIT
AMSTERDAM
Notation Elements (1/2)
Name Notation Description
Lifeline
Interaction partners involved in
the communication
Destruction
event
Time at which an interaction partner
ceases to exist
Combined
fragment
Control constructs
44

45. VRIJE
UNIVERSITEIT
AMSTERDAM
Notation Elements (2/2)
Name Notation Description
Synchronous
message
Sender waits for a response message
Response
message
Response to a synchronous message
Asynchronous
communication
Sender continues its own work
after sending the asynchronous
message
Lost message Message to an unknown receiver
Found message
Message from an unknown
sender
45

46. VRIJE
UNIVERSITEIT
AMSTERDAM
What this lecture means to you?
• You can model how objects interact with each other now!
• Use case
• main features of the system
• how external actors interact with them
• Class diagram
• main entities of your system
• data types
• Object diagram
• snapshots of your system at run-time
• State machine diagram
• internal behaviour of your objects
• Sequence diagram
• how objects interact with each other (aka external behaviour)
• actors and users also involved here 46

47. VRIJE
UNIVERSITEIT
AMSTERDAM
Readings
• UML@Classroom: An Introduction to Object-Oriented
Modeling” – chapter 6
• Learning UML 2.0 – chapter 7
47