Modeling objects interaction via UML sequence diagrams [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]

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

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

VRIJE
UNIVERSITEIT
AMSTERDAM
3

VRIJE
UNIVERSITEIT
AMSTERDAM
4

VRIJE
UNIVERSITEIT
AMSTERDAM
5

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

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

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

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

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

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:

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

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

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

VRIJE
UNIVERSITEIT
AMSTERDAM
Combined fragments
15

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

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

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

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

VRIJE
UNIVERSITEIT
AMSTERDAM
loop Fragment
§ 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

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

VRIJE
UNIVERSITEIT
AMSTERDAM
loop and break Fragment - Example
22

VRIJE
UNIVERSITEIT
AMSTERDAM
Operator Purpose
seq Weak order
strict Strict order
Branchesand
loops
Concurrencyand
order
Filtersand
assertions
23

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

VRIJE
UNIVERSITEIT
AMSTERDAM
seq Fragment – Example
25

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

VRIJE
UNIVERSITEIT
AMSTERDAM
strict Fragment - Example
27

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

VRIJE
UNIVERSITEIT
AMSTERDAM
par Fragment - Example
29

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

VRIJE
UNIVERSITEIT
AMSTERDAM
critical Fragment - Example
31

VRIJE
UNIVERSITEIT
AMSTERDAM
Operator Purpose
seq Weak order
strict Strict order
Branchesand
loops
Concurrencyand
order
Filtersand
assertions
32

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

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

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

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

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

VRIJE
UNIVERSITEIT
AMSTERDAM
Further language elements
38

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

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

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

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

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

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

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

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

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

Modeling objects interaction via UML sequence diagrams [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]

More Related Content

Viewers also liked

Similar to Modeling objects interaction via UML sequence diagrams [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]

More from Ivano Malavolta

Recently uploaded

Modeling objects interaction via UML sequence diagrams [Software Modeling] [Computer Science] [Vrije Universiteit Amsterdam] [2016/2017]