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 SciencesVrije Universiteit Amsterdam

VRIJEUNIVERSITEITAMSTERDAM

Modeling objects interactionvia UML sequence diagrams

Software modeling (401016) – 2016/2017

Ivano [email protected]


Examples of questions in the final exam (1)

2



3



4



5


Roadmap

§ Introduction§ Basics

§ Interactions and interaction partners§ Messages

§ Combined fragments§ Branches and loops§ Concurrency and order§ Filters and assertions

§ Further language elements

6


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 GOALTo model interactions between objects


Sequence Diagram

§ Two-dimensional diagram § Horizontal axis: involved interaction partners§ Vertical axis: chronological order of the interaction

§ Interaction = sequence of event specifications

8


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


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


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:


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


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


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


Combined fragments

15


Combined Fragments

§ Model various control structures§ 12 predefined types of operators

Operand

Operand

Combined Fragment

Operator

Operand

16


Types of Combined Fragments

Operator Purposealt 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

Bra

nch

es

and

lo

op

sC

on

curr

en

cy a

nd

o

rde

r

Filt

ers

an

d

asse

rtio

ns

17


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


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


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 isexecuted at least once, then as long asa<1 is true

MinGuard

Max

To model repeated sequences


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 surroundingfragment are omitted§ (d)

§ Interaction continues in the next higherlevel fragment § (e)

Not executed if break is executed

To model exception handling


loop and break Fragment - Example

22







seq Weak order

strict Strict order







Bra

nch

es

and

lo

op

sC

on

curr

en

cy a

nd

o

rde

r

Filt

ers

an

d

asse

rtio

ns

23


seq Fragment

§ Weak sequencing:1. Events on different lifelines from different operands may come

in any order2. 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


seq Fragment – Example

25


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


strict Fragment - Example

27


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


par Fragment - Example

29


critical Fragment

§ To make sure that certain parts of an interaction are not interrupted by unexpected events

30

Atomic area


critical Fragment - Example

31







seq Weak order

strict Strict order







Bra

nch

es

and

lo

op

sC

on

curr

en

cy a

nd

o

rde

r

Filt

ers

an

d

asse

rtio

ns

32


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


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


ignore vs. consider

35These are the same


assert Fragment

§ Deviations that occur in reality but that are not included in the diagram are not permitted

36

To represent mandatory interactions


neg Fragment

§ Describing situations that must not occur§ Purpose

§ Explicitly highlighting frequently occurring errors§ Depicting relevant, incorrect sequences

37

To explicitly represent invalid interactions


Further language elements

38


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


Interaction Reference

§ Integrates one sequence diagram in another sequence diagram

40

DefinitionUsage


Gate

§ Allows you to send and receive messages beyond the boundaries of the interaction fragment

41


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

Localattributes

42


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


Notation Elements (1/2)

Name Notation Description

Lifeline Interaction partners involved inthe communication

Destruction event

Time at which an interaction partnerceases to exist

Combined fragment Control constructs

44


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 workafter sending the asynchronousmessage

Lost message Message to an unknown receiver

Found message Message from an unknownsender

45


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


Readings

• UML@Classroom: An Introduction to Object-Oriented Modeling” – chapter 6

• Learning UML 2.0 – chapter 7

47

Technology

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