1

Module

3: A

dvanced F

eatu

res –

Part

II: B

ehavio

ral D

iagra

ms

2

3 b

asic

build

ing b

locks o

f U

ML

-D

iag

ram

sG

raphic

al re

pre

senta

tion o

f a

set

of ele

ments

.

Repre

sente

d b

y a

connecte

d g

raph: V

ert

ices a

re t

hin

gs; A

rcs a

re r

ela

tionship

s/b

ehavio

rs.

5 m

ost

com

mon v

iew

s b

uilt

fro

m

UML 1.x: 9 diagram types.

UML 2.0: 12 diagram types

Behavio

ral D

iagra

ms

Represent the dynamicaspects.

–U

se c

ase

–S

equence;

Colla

bora

tion

–S

tate

chart

–A

ctivity

Str

uctu

ral D

iagra

ms

Represent the static aspects of a system.

–C

lass;

Obje

ct

–C

om

ponent

–D

eplo

ym

ent

Behavio

ral D

iagra

ms

–U

se c

ase

–S

tate

chart

–A

ctivity

Str

uctu

ral D

iagra

ms

–C

lass;

Obje

ct

–C

om

ponent

–D

eplo

ym

ent

–C

om

posite S

tructu

re

–P

ackage

Inte

raction D

iagra

ms

–S

equence;

Communication

–In

tera

ction O

verv

iew

–T

imin

g

3

Use C

ase D

iagra

ms

Behavio

ral D

iagra

ms

–Use case

–S

tate

chart

–A

ctivity

Inte

raction D

iagra

ms

–S

equence;

Communication

–In

tera

ction O

verv

iew

–T

imin

g

4

Use Cases

�S

cenarios

describe a

sin

gle

path

, or

a p

art

icula

r sequence

�E

.g., U

se C

ase:

Ord

er

Goods

�S

cenario 1

: all

goes w

ell

�S

cenario 2

: in

suffic

ient fu

nds

�S

cenario 3

: out o

f sto

ck

�S

yste

m test cases: G

enera

te a

test script fo

r each s

cenario (

flow

of

events

).

�O

bta

in initia

l sta

te f

rom

pre

conditio

ns.

�T

est success a

gain

st post conditio

ns.

�W

hen to U

se

Use C

ases

�F

ow

ler’s V

iew

: do u

se c

ases f

irst

befo

re o

bje

ct

modelin

g

�C

aptu

re t

he sim

ple, norm

al use-case

firs

t

�F

or

eve

ry s

tep

ask “What could go wrong?”

and h

ow

it

mig

ht

wo

rk o

ut diffe

rently

�P

lot all

variations a

s extension

s o

f th

e g

iven u

se c

ase

�A

noth

er

vie

w:

do o

bje

ct

mod

elin

g f

irst,

then u

se c

ases

�A

noth

er:

ite

rate

model -

use c

ase -

model -

use c

ase .

..What did we do?

5

Organizing U

se Cases

•G

enera

lization,

Exte

nd,

Inclu

de/U

se, packages

Track order

gen

eraliza

tion

Validate user

Retinal scan

Check password

Place rush order

Place order

Extension points:

set priority

extension

inclusion

extensionpoint

<<extend>>

(set priority)

<<include>

>

<<include>

>

•Track O

rder-Obtain and verify the order number; For each part in the order,query its status,

then report back to the user.

•Place O

rder-Collect the user’s order items. (set priority). Submit the order for processing.

com

mo

n to

multip

le u

se c

ase

s;

Often no

acto

r m

ay b

e a

ssocia

ted

with a

‘used’use c

ase

UML 1.3: Replaces <<uses>> relationship with Generalization and <<include>> dependency (http://www.jeckle.de/files/viewfront.pdf)

does a bit m

ore or deals w

ith a special situation

extension use case

inclusion use case

child use case

base use case

6

A AAAUse Case Template

(htt

p:/

/ww

w.b

rede

me

ye

r.com

/pdf_

file

s/u

se_

ca

se

.pdf)

No

n-F

un

ctio

na

l (o

ptio

na

l)L

ist of

NF

Rs th

at th

e u

se c

ase m

ust m

ee

t

Issu

es

Lis

t of

issue

s th

at re

ma

in to b

e r

eso

lve

d

Diffe

rence fo

r th

e s

pe

cific

su

bflo

wA

lt. flo

w o

f e

ve

nts

/sub

flo

ws

Wha

t sh

ou

ld h

old

afte

r th

e u

se c

ase s

ucce

ssfu

lly c

om

ple

tes.

Po

stc

on

ditio

ns

Su

bflo

ws m

ay b

e d

ivid

ed

in

to 1

) n

orm

al, 2

) successfu

l a

lte

rnate

action

s, a

nd 3

) e

xce

ptio

n/e

rro

r flo

ws.

Exce

ptio

n f

low

s

Th

e h

ap

py/s

un

ny d

ay f

low

. T

he

mo

st co

mm

on s

ucce

ssfu

l ca

se.

Ba

sic

flo

w o

f e

ve

nts

Wha

t sh

ou

ld b

e tru

e b

efo

re the

use c

ase c

an s

tart

.P

reco

nd

itio

ns

Goal: E

.g., “

Th

is u

se

case

lets

a b

ank a

cco

unt

ow

ne

r w

ith

dra

w

mo

ne

y f

rom

an

AT

M m

ach

ine”;

Source:

Ba

nk d

oc 2

.3

Bri

ef d

escri

ptio

n

Lis

t of a

cto

rs in

vo

lve

d in

use c

ase

Acto

rs

Ide

ntifier:

e.g

., “

With

dra

w m

on

ey”;

ref

# =

wm

3;

mo

d h

isto

ry =

…U

se

Ca

se

7

A Use C

ase Template

What

are

the

mode

s o

f co

mm

un

ica

tion

be

twe

en

fie

ld m

ain

tena

nce

en

gin

ee

r and

ope

rato

rIs

su

es (

tha

t re

ma

in to

be

reso

lved

)

Pe

rfo

rma

nce

Me

an

: tim

e to

repa

ir n

etw

ork

fau

lt m

ust b

e le

ss tha

n3 h

ou

rsN

on

-Fun

ctiona

l (o

ptiona

l)

#1

. S

yste

m m

ay d

ete

ct fa

ult a

nd

no

tify

ope

rato

r o

r

Fie

ld m

ain

tenan

ce e

ngin

ee

r m

ay r

epo

rt f

au

lt t

o O

pe

rato

r

Va

ria

tio

ns (

op

tiona

l)

1.

Op

era

tor

no

tifie

d o

f n

etw

ork

pro

ble

m

2.

Op

era

tor

sta

rts r

epa

ir s

essio

n

3.

RE

PE

AT

3.1

Ope

rato

r ru

ns n

etw

ork

dia

gno

sis

app

lica

tio

n

3.2

Ope

rato

r id

en

tifie

s c

ells

to

be

change

s a

nd

the

ir n

ew

pa

ram

ete

r va

lue

s

3.3

IN P

AR

ALLE

L

3.3

.1 M

ain

tena

nce

en

gin

ee

r te

sts

ne

two

rk c

ells

||

3.3

.2 M

ain

tena

nce

en

gin

ee

r send

s fa

ult r

ep

ort

s

UN

TIL

no

mo

re r

ep

ort

s o

f p

roble

m

4.

Ope

rato

r clo

se

s r

epa

ir s

essio

n

Ste

ps

Chan

ge

s to

ne

two

rk a

re a

lwa

ys s

ucce

ssfu

l w

he

n a

pp

lied

to

a n

etw

ork

Assum

ption

s (

su

cce

ssfu

l u

se

ca

se

te

rmin

ation

cond

itio

n)

Op

era

tor

(prim

ary

, C

ellu

lar

ne

two

rk,

Fie

ld m

ain

tenan

ce

en

gin

ee

r)A

cto

rs

Op

era

tor

rectifie

s a

repo

rt b

y c

han

gin

g p

ara

me

ters

of

a c

ell

De

scrip

tion

(goa

l, s

ou

rce

)

2.

Repa

rin

g_

Ce

llula

r_N

etw

ork

His

tory

cre

ate

d 1

/5/9

8 D

ere

k C

ole

ma

n, m

od

ifie

d 5

/5/9

8

Use

Ca

se

(id

, re

f#,

mod

his

tory

)

(htt

p:/

/ww

w.b

rede

me

ye

r.com

/pdf_

file

s/u

se_

ca

se

.pdf)

Ho

w a

re fa

ilure

s d

ete

cte

d?

Are

roll

ba

cks a

uto

ma

tic o

r is

Ope

rato

r in

terv

en

tion

re

qu

ired?

Issu

es

#3.3

.if th

e c

han

ge

s to

ne

two

rk f

ail

then

th

e n

etw

ork

is r

olle

d b

ack t

o its

pre

vio

us s

tate

Ste

ps

Dea

ls w

ith

assum

ption t

ha

t ne

two

rk c

ha

nge

s c

an

ne

ve

r fa

ilD

escrip

tion

Repa

ir_m

ay_

fail

exte

nd

s 2

. R

epa

rin

g_

Ce

llula

r_N

etw

ork

Use

Ca

se

Exte

nsio

n

8

Sequence D

iagra

ms

Behavio

ral D

iagra

ms

–U

se c

ase

–S

tate

chart

–A

ctivity

Inte

raction D

iagra

ms

–Sequence

;

Communication

–In

tera

ction O

verv

iew

–T

imin

g

9

Interaction Diagrams (sd and cd)

�sho

w t

he inte

raction o

fany kind ofinstance (classes, interfaces, components,

nodes and subsystems);

�m

essages s

ent/

receiv

ed b

y t

hose o

bje

cts

/insta

nces (

invocation,

constr

uction/d

estr

uction,

of

an o

pera

tio

n)

�re

aliz

es u

se c

ases t

o m

odel a s

cenari

o

�In

tera

ction t

yp

es (

these a

re isom

orp

hic

, w

hen n

o lo

ops o

r bra

nch

ing)

–S

equence

dia

gra

m—

em

phasiz

es the tim

e o

rdering

of m

essages.

–C

om

munic

ation

(Colla

bora

tion)

dia

gra

m—

em

phasiz

es the s

tructu

ral org

aniz

ation o

f obje

cts

th

at directly s

end a

nd r

eceiv

e m

essages.

�O

bje

cts

within

an inte

raction c

an b

e:

–C

oncre

te:

som

eth

ing f

rom

the r

eal w

orld.

(e.g

., John: Person)

–P

roto

typic

al:

repre

se

nta

tive insta

nce o

f som

eth

ing f

rom

the

real w

orl

d

(e.g

., p: Person)

•C

om

mun

icatio

n d

iagra

ms u

se (

str

ictly)

pro

toty

pic

al th

ings.

•P

roto

typ

ical in

sta

nces o

f in

terf

aces a

nd a

bstr

act

types a

re v

alid

.

10

Interaction Diagram: sequencevs communication

s1 : StockQuoteSubscriber

p : StockQuotePublisher attach(s1)

s2 : StockQuoteSubscriber

attach(s2)

notify()

update()

update()

getState()

getState()

s1 : StockQuoteSubscriber

p : StockQuotePublisher

s2 : StockQuoteSubscriber

1 : attach(s1)

6 : getState()

2 : attach(s2)

7 : getState()

3 : notify()

4 : update()

5 : update()

Observer

design

pattern

object

role:ClassName

Procedure call, RMI, JDBC, …

Activations (See pg 17)

-S

ho

w d

ura

tion

of

execu

tio

n

-S

ho

ws c

all

sta

ck

-R

etu

rn m

essa

ge

Imp

licit a

t en

d o

f a

ctiva

tion

Exp

licit w

ith

a d

ashed

arr

ow

objects

Tim

e

{update

< 1

min

ute

s}

classifiers or their instances,

use cases or actors.

11

Interactions -Modeling Actions

•S

imple

•C

all

•R

etu

rn

•S

end

: TicketAgent

c : Client

p : PlanningAgent

<<create>>

setItenerary( i )

calculateRoute()

route

Xnotify()

return value

send

call on self

<<destroy>>

actual parameter

return

end of object life

destroy: e.g., in C

++ m

anual garbage co

llection; in Java

/C#, unnecessary

Additional co

nsiderations

�T

o s

how

neste

d m

essages, use ?

.

�T

o s

how

constr

ain

ts lik

e tim

e a

nd s

pace, use ?

.

�F

or

form

al flow

of contr

ol, a

ttach p

re a

nd p

ost conditio

ns to e

ach m

essage (?

)

1

natural dea

th/

self destruction

asynchronous in 2.0 (stick arrowhead) –no return value expected at end of callee activation

half arrow in 1.x

activation of caller may end before callee’s

(???)

(???)

(???)

(???)

for each conference

loop

12

concurrent lifelines

-for conditionals

-for concurrency

linking sequence diagrams

ob1:C

1

ob3:C

3

ob2:C

2

ob3:C

3

op1

[x>

0] fo

o(x

)

[x<

0] bar(

x)

do(w

)

do(z

)

recurs

e()

[z=

0] ja

r(z)

ob3:C

3

[z=

0] ja

r(z)

ob3:C

3

conditional

recursion

Sequence Diagrams –

Generic vs. Instance

�2 f

orm

s o

f sd:

�Instance

sd:

describes a

specific

scenario in d

eta

il; n

o c

on

ditio

ns, bra

nches o

r lo

ops.

�Generic

sd:

a u

se c

ase d

escription w

ith a

lte

rnative c

ours

es.

Here, conditional or concurrency?

13

Tim

ing constraints

�U

sefu

l in

real-tim

e a

pplic

ations

�usefu

l to

specify r

ace c

onditio

n b

ehavio

ur

�T

wo w

ays to s

pecify (

in 1

.x)

any example?

14

Interactions -

Procedural Sequencing vs. Flat Sequencing

Fla

t S

equ

encin

g•

Infr

equent: Not recommended for most

situations.

•E

ach m

essage is n

um

bere

d s

equentially

in

ord

er

of tim

ing.

•R

endere

d w

ith s

tick

arr

ow

head.

c : Client

xx.k

c : Client

xy

7

4 5 6

1 2 3

CAN’T

TELL R

ELATIO

NSHIP

S

Pro

ce

du

ral S

eq

ue

ncin

g

(Dew

ey d

ecim

al syste

m)

•M

ost com

mon.

•E

ach m

essage w

ithin

the s

am

e o

pera

tion is

num

bere

d s

eque

ntially

.

•N

este

dm

essages a

re p

refixed w

ith the

sequence n

um

ber

of

the invokin

g o

pera

tion.

•R

endere

d w

ith fill

ed s

olid

arr

ow

.

8 9

3.1.1

1.1

1.2

3.1

1 2 3

1.1.1

1.1.2

15

:Eunconditional

Interactions –

conditional paths, asynchronous m

essage

[Cra

ig L

arm

an

] [h

ttp

://w

ww

.php

tr.c

om

/art

icle

s/a

rtic

le.a

sp?

p=

36

0441

&se

qN

um

=6

&rl=

1]

:A :C

:B :D

1: m

sg1

1a [te

st1

]:m

sg2

2: m

sg7

1b [not

test1

]:m

sg3

1c: m

sg4

a.1:<<create>>

1a and 1b are mutually

exclusive conditional paths

1c.1

: m

sg5

active object

asynchrous message

a.2:update( p )

:F

Is this ok?

Can you produce a corresponding sd?

Is there a unique sequence of paths?

16

Use Case

Modeling Different Levels of Abstraction

Interaction Diagram at a High Level of Abstraction

: Order Clerk

: Order Taker

: Order

Fulfillm

ent

submitOrder

placeOrder

acknowledgeOrder

Interaction Diagram at a Lower Level of Abstraction

: Order Clerk

: Order Taker

: Order

Fulfillm

ent

: Billing Agent

: CreditCard

Agen

submitOrder

placeOrder

processCard

acknowledgeOrder

triggerB

ill

Order Clerk

Place O

rder

�E

sta

blis

h t

race

depen

dencie

s b

etw

ee

n h

igh a

nd lo

w levels

of

abstr

action

�Loosely couple different levels of abstraction

•Use Cases

trac

e to

Collaborations

in the Design M

odel, t

o a

soci

ety

of classes

•Components

trac

e to

the

elem

ents

in th

e de

sign

mod

el, t

hen

to Nodes

<<

trace>

>

<<

trace>

>

model

17

public Class Selection

{private

Purc

hase m

yP

urc

hase =

new

Purc

hase()

;

private Payment myPayment;

public void purchase()

{m

yP

urc

hase.b

uyM

ajo

r();

myP

urc

hase.b

uyM

inor(

):

myPayment = new Payment( cashTender );

//..

}

// ..

}

:Sele

ction

:Purc

hase

:Paym

ent

purc

hase

buyM

ajo

r

buyM

inor

cre

ate

(ca

shT

ende

r)

Sequence Diagrams & Some Programming

18

�Why do people call it an ATM m

achine, but they know it's

really saying Automated Teller Machine M

achine?

�Why do people say PIN

number when that truly m

eans

Personal Identification Number Number?

19

sd W

ithdra

wal

:User

:AT

M:B

ank

ref

Authenticate

alt

alt

PIN O

K

PIN NOK

with

dra

w

msg (

“am

oun

t”)

am

oun

t (a

)ch

kA

cct

(a)

msg (

“ca

rd”)

msg (

“ille

gal en

try”)

en

ou

gh

ba

l

no

t enou

gh

ba

l

mone

y

rece

ipt

msg(“

am

oun

t to

o b

ig”)

sd A

uth

enticate

:User

:AT

M:B

ank

ref

EnterP

IN

loop(0

,3)

PIN NOK

msg (

“try

aga

in”)

ca

rdId

(cid

)Idle

ref

EnterP

IN

sd E

nte

rPIN

:User

:AT

M:B

ank

PIN NOK

pin

-no

k

Dig

it[4

]

alt

pin

-ok

PIN NOK

Code

(cid

,pin

)

Frames: References

continuation

nested fragment

operandsoperator

20

Interaction O

verview Diagram

-variants

on U

ML a

ctivity d

iagra

ms

wh

ich o

ve

rvie

w c

ontr

ol flo

w.

-nodes a

re f

ram

es inste

ad o

f activitie

s.

-tw

o t

ypes o

f fr

am

e:

> inte

raction f

ram

es -

an

y t

ype o

f U

ML inte

raction d

iagra

m (

sd,

cd,

td, io

d)

or

> inte

raction o

ccurr

ence f

ram

es (ref)

whic

h indic

ate

an a

ctivity o

r op

era

tion t

o invoke.

21

sd W

ithdra

wal

:User

:AT

M:B

ank

ref

Authenticate

PIN O

KPIN NOK

with

dra

w

msg (

“am

oun

t”)

am

oun

t (a

)ch

kA

cct

(a)

msg (

“ca

rd”)

msg (

“ille

gal en

try”)

no

t enou

gh

ba

lm

sg(“

am

oun

t to

o b

ig”)

Interaction O

verview Diagram

:User

:AT

M:B

ank

sd

:User

:AT

M

sd

:User

:AT

M

sd

en

ou

gh

ba

lm

one

y

rece

ipt

:User

:AT

M:B

ank

sd

sd

Relationship with Sequence Diagram?

22

Frames & Interaction Fragment Operators

Flo

w o

f C

ontr

ol

–sd

: nam

ed s

equence d

iagra

m r

ef: r

efe

rence to “

inte

raction fra

gm

ent”

Nam

ing

–lo

op

: r

epeat in

tera

ction fra

gm

ent

–opt: o

ptional “e

xem

pla

r”(c

f. b

rea

k)

–alt: sele

ction

–par:

concurr

ent (p

ara

llel) r

egio

ns (

e.g

., m

o.c

ookF

ood -

> p

ar(

nukeF

ood, ro

tate

Food)

Ord

ering

–seq

: part

ial ord

ering (

defa

ult)

(aka “

weak”)

–str

ict: s

tric

t ord

ering

–criticalR

egio

n: id

entifies “

ato

mic

”fr

agm

ents

Causalit

y

–assert

: re

quired (

i.e. causal)

–neg

: “c

an’t h

appen”

or

a n

egative s

pecific

ation

–Ig

nore

/consid

er:

messages o

uts

ide/insid

e c

ausal str

eam

Frame:

as t

he g

raphic

al bo

und

ary

, an

d a

lab

elin

g m

echan

ism

Frame name:

“fr

am

e t

yp

e n

am

e[(

para

m t

ype:

para

m n

am

e)]

[:

retu

rn t

ype:

retu

rnnam

e]”

[guard

con

ditio

n]

can a

ppe

ar

as t

he f

irst

item

undern

eath

23

What can be in the top boxes?

(htt

p://w

ww

.agile

mo

delin

g.c

om

/art

ifa

cts

/se

que

nceD

iag

ram

.htm

)

Outputting

transcripts

Boundary/interface elements

: softw

are

ele

ments

such a

s s

cre

ens, re

port

s, H

TM

L p

ages, or

syste

m inte

rfaces that acto

rs inte

ract w

ith.

Control/processelements (controllers):

These s

erv

e a

s the g

lue b

etw

een b

oundary

ele

ments

and e

ntity

ele

ments

, im

ple

menting the logic

require

d to m

anage the v

arious e

lem

ents

and their

inte

ractions.

Often im

ple

mente

d u

sin

g o

bje

cts

, but sim

ple

ones u

sin

g m

eth

ods o

f an e

ntity

or

boundary

cla

ss.

Entity

elements

24

Modeling Protocols

-Associating Protocols w

ith Ports

«interface»

Callee

««interface

interface»»

Callee

Callee

«interface»

Caller

««interface

interface»»

Caller

Caller

«interface»

Operator

««interface

interface»»

Operator

Operator

Cla

ssX

Cla

ssX

�B

y a

set of interconnected interfaces,in

voked a

ccord

ing to a

form

al

behavioral specific

ation.

ca

ller

ca

ller

ca

ller

op

era

tor

op

era

tor

op

era

tor

ca

llee

ca

llee

ca

llee

Interaction specs

initia

lin

itia

lin

itia

l

con

ne

cte

dcon

ne

cte

dcon

ne

cte

d

con

ne

ctin

gcon

ne

ctin

gcon

ne

ctin

g

state machine spec

Operator Assisted Call

Operator Assisted Call

«uses»

«uses»

«provides»

Can you depict this using balls & sockets?

25

call

ack

number

call

ack

talk

transfer

Caller

Caller

Caller

Operator

Operator

Operator

Callee

Callee

Callee

Protocols: Reusable Interaction Sequences

(http://cot.uni-mb.si/ots2003/ppt/Selic-U

ML2.0-tutorial.030504.pdf)

�C

om

munic

ation s

equences that

�alw

ays follo

w a

pre

-defined d

ynam

ic o

rder

�occur

in d

iffe

rent conte

xts

with d

iffe

rent specific

part

icip

ants

(i.e

., insta

nces)

Interfaces

26

From Diagrams to O

bjects

Colle

ct all

messages to d

efine o

bje

ct’s m

eth

ods a

nd

sta

te tra

nsitio

ns !

Ph

on

e

Dir

ecto

ry

27

Sta

te T

ransitio

n D

iagra

ms

Behavio

ral D

iagra

ms

–U

se c

ase

–Statechart

–A

ctivity

Inte

raction D

iagra

ms

–S

equence;

Com

munic

ation

–In

tera

ction O

verv

iew

–T

imin

g

28

State Transitions

even

t name [guard condition] / action

^object/className.even

t

15 sec

send

•State machine

-event-

ord

ere

dbehavio

r th

at

specifie

s t

he s

eque

nces o

f states

an o

bje

ct/

insta

nce (

of

cla

ss/in

terf

ace/c

olla

bo

ration/…

/syste

m)

goes t

hro

ug

h

durin

g its

lifetim

e; events

trig

ger transitions

and c

ause responses.

(Sta

teC

ha

rt is o

ne p

art

icula

r kin

d o

f sta

te m

achin

e b

y D

avid

Hare

l)

•State

-conditio

n o

r situation d

uring w

hic

h a

n o

bje

ct/

insta

nce

ma

y p

erf

orm

som

e

activity;

The s

tate

of

an o

bje

ct

is c

hara

cte

rized b

y t

he v

alu

e o

f one o

r m

ore

of

its

att

ribute

s.

•Activity

-ongo

ing non-atomic

executio

n w

ithin

a s

tate

machin

e.

•Action

-execu

table

atomic c

om

puta

tion t

hat

results in a

cha

nge in s

tate

of

the

model or

the r

etu

rn o

f a v

alu

e.

even

t name (a:T

) [guard condition] / action

29

State Transitions

initia

liza

tion

open

add stu

den

t

[count<

10]

cance

lca

nce

lclose

d

cance

led

add stu

den

t/ set

count=

0;^

Cours

eRoster

.cre

ate(

cours

e)

[count=

10]

^Cours

eRoster

.del

ete

triggerless transition

guard

action

event trigger

send signal

�E

ach d

iagra

m m

ust have o

ne a

nd o

nly

one s

tart

sta

te

�A

dia

gra

m m

ay h

ave o

ne o

r m

ore

sto

p s

tate

s

�A

uto

matic tra

nsitio

n -

occurs

when the a

ctivity o

f o

ne s

tate

com

ple

tes

�N

on-a

uto

matic tra

nsitio

n -

caused b

y a

nam

ed e

vent

30

State Transitions –notational variation

open

cance

l

close

d

cance

led

[count=

10]

open

cance

l

close

d

cance

led[count=

10]

open

cance

l

close

d

cance

led

not ca

nce

l an

d [co

unt=

10]

-se

man

tic-f

ree

ve

rtic

es,

-u

sed

to

cha

in t

oge

ther

mu

ltip

le t

ran

sitio

ns.

-U

ML

2.0

Supe

rstr

uctu

re S

pe

cific

ation

, p

. 5

91

Junction pseudo state

-dyn

am

ic c

on

ditio

na

l b

ran

ch

.

--sp

littin

g o

f tr

an

sitio

ns in

to m

ultip

le o

utg

oin

g p

ath

s

--U

ML

2.0

Supe

rstr

uctu

re S

pe

cific

ation

, p

. 5

92

)

Choice pseudo state

31

State Transitions –History States

-used t

o r

em

em

ber

the p

revio

us s

tate

of

a s

tate

machin

e w

he

n it

was inte

rru

pte

d.

http://w

ww

.sparx

syste

ms.c

om

/resourc

es/u

ml2

_tu

torial/um

l2_sta

tedia

gra

m.h

tml

Cf.

deep h

isto

ry s

tate

(H

*) –

the r

ecentm

ost

sta

te in t

he r

ecentm

ost

sta

te in …

32

Advanced States

�Entry & exit actions

-actions that alw

ays o

ccur

upon e

ntr

y into

or

exit a

way fro

m a

sta

te r

egard

less o

f tr

ansitio

n.

�Internal Transitions

-tr

iggere

d b

y e

vents

but don’t c

hange s

tate

.

�Activities

-ongoin

g b

ehavio

r w

hic

h c

ontinues u

ntil in

terr

upte

d.

�Deferred events

-events

ignore

d b

y the c

urr

ent sta

te, but postp

oned

fo

r la

ter

pro

cessin

g.

Tra

ckin

g

entr

y /

setM

ode(

onT

rack )

exit /

setM

ode(

off

Tra

ck )

ne

wT

arg

et

/ tr

acker.

Acquire()

do /

follo

wT

arg

et

selfT

est /

defe

r

entry action

exit action

internal transition

activity

deferred event

name

33

Substates

�S

ubsta

te -

-sta

te n

este

d insid

e o

f anoth

er

sta

te.

�S

equential substa

tes (

then a

nonort

hogonal sta

te)

�C

oncurr

ent substa

tes (

then a

n o

rthogonal sta

te)

Idle

Main

tenance

Active

Valid

ating

Sele

cting

Pro

cessin

g

Printing

[not continue]

entr

y / r

eadC

ard

exit / e

jectC

ard

[continue]

sequential substate

composite state

main

tain

card

Insert

ed

cancel

Idle

Main

tenance

Testing

Com

mandin

g

H H

Testing

devic

es

Waitin

g

Self

dia

gnosis

Com

mand

main

tain

composite state

concurrent

substate

[continue]

join

fork

[not continue]

keyP

ress

Initial state/ pseudostate

34

Verify

Card

OutO

fServ

ice

acce

ptC

ard

Rele

aseC

ard

Verify

Tra

nsaction

outO

fServ

ice

rele

ase

Ca

rdATM

ReadA

mount :

ReadA

mountS

Maborted

aborted

reje

ctT

ran

sa

ctio

n

again

again

Modular Submachines

usage of

exit point

usage of

exit point

usage of

entry point

usage of

entry point

invoked

submachine

invoked

submachine

ReadAmountSM

sele

ctA

mount

Ente

rAm

ount

ok

abort

aborted

aborted

am

ount

oth

erA

mount

abort

again

again

EXIT point

EXIT point

ENTRY point

ENTRY point

Submachine

definition

Submachine

definition

htt

p:/

/ww

w.x

pd

ian

.com

/UM

L2

.0cha

nge

s.h

tml

-A c

om

posite s

tate

may h

ave s

evera

l entr

y a

nd e

xit p

oin

ts;

-how

does e

ntr

y p

oin

t diffe

r fr

om

H/H

*?

-pro

mote

s r

euse (

next

slid

e)

35

Specialization

•R

edefinitio

n a

s p

art

of sta

ndard

cla

ss s

pecia

lizatio

n

AT

M

acceptC

ard

()outO

fServ

ice()

am

ount(

)

Behaviour

Statemachine

Fle

xib

leA

TM

oth

erA

mou

nt(

)re

jectT

ransaction()

Behaviour

Statemachine

<<Redefine>>

36

Events –

External vs. Intern

al Events

�E

vents

can b

e c

ate

gorized into

exte

rnal or

inte

rnal events

.

�Externalevents

are

those that pass b

etw

een the A

cto

rs a

nd the s

yste

m.

System

Event

Event

NetworkElement

elementPort: Port

�Internalevents

pass b

etw

een o

bje

cts

resid

ing w

ithin

the a

pp

lication s

yste

m.

NetworkController

consolePort[2..*] : Port1

37

•Signal-

kin

d o

f eve

nt

that

rep

rese

nts

the s

pecific

ation o

f a

n

asynchronous

stim

ulu

s c

om

mu

nic

ate

d b

etw

een insta

nces.

•M

od

ele

d a

s a

cla

ss

•D

ispatc

he

d (

thro

wn)

by o

ne

obje

ct

and c

ontin

ues f

low

of

executio

n

•R

eceiv

ed (

ca

ught)

by a

noth

er

obje

ct

at

so

me f

utu

re p

oin

t in

tim

e.

•C

an b

e s

ent as:

–A

ction o

f a s

tate

tra

nsitio

n

–M

essage in a

n o

bje

ct

inte

raction

–D

epe

nde

ncie

s <

<send>

> s

how

sig

na

ls s

ent

by a

cla

ss

moveTo

position

velocity

MovementA

gent

<<signal>>

Collision

force : float

<<send>>

send dependency

Signal parameters

signal

Signals

collision( force : float )

powerLoss

powerD

own

TroubleManager

•M

odelin

g S

ign

al R

ece

iver:

as a

n a

ctive c

lass; C

onsid

er

4th

co

mpart

ment fo

r sig

nals

.

Events –

4 K

inds: Signals

; C

alls

; P

assin

g o

f T

ime; C

hange in S

tate

38

Call Events

�R

epre

sents

the

dis

patc

h o

f an o

pera

tion

�Synchronous

Automatic

Manual

startAutopilot( norm

al )

event parameter

Tim

e & C

hange Event

•T

ime e

vent

-re

pre

sents

the p

assage o

f tim

e:

after( periodOfTime )

•C

hange e

vent -

repre

sents

a c

han

ge in s

tate

or

the s

atisfa

ction o

f som

e c

onditio

n:

when( booleanExpr )

time event

Idle

Active

when( 11:49pm ) / selfTest()

after( 2 sec ) / dropConnection()

change event

Events –

4 K

inds: S

ignals

; Calls; Passing of Time; Change in State

39

Modeling Family of Signals and Exceptions

�S

ignal events

are

typic

ally

hie

rarc

hic

al.

�Look for

com

mo

n g

enera

lizations.

�Look for

poly

mo

rphic

opport

unitie

s.

<<signal>>

RobotSignal

<<signal>>

HardwareFault

<<signal>>

Collision

sensor : int

<<signal>>

MotorS

tall

<<signal>>

MovementFault

<<signal>>

BatteryFault

<<signal>>

VisionFault

<<signal>>

RangingFault

�C

onsid

er

the

exceptional conditio

ns o

f each c

lass.

�A

rrange e

xceptions in g

enera

lization h

iera

rch

y.

�S

pecify the

exce

ptions that each o

pera

tion m

ay r

ais

e.

–U

se s

end d

ependencie

s

–S

how

in o

pera

tion s

pecific

ation

setH

andler()

firstH

andler()

lastH

andler()

<<exception>>

Exception

<<exception>>

Duplicate

<<exception>>

Underflow

<<exception>>

Overflow

add()

remove()

Set

item

<<send>>

<<send>>

<<send>>

40

Activity D

iagra

ms

Behavio

ral D

iagra

ms

–U

se c

ase

–S

tate

chart

–Activity

Inte

raction D

iagra

ms

–S

equence;

Com

munic

ation

–In

tera

ction O

verv

iew

–T

imin

g

41

Activity Diagram Basics

•Activity Diagram

–a s

pecia

l kin

d o

f S

tate

cha

rt d

iagra

m, bu

t show

ing t

he f

low

fro

mactivity to

activity (

not

from

sta

te t

o s

tate

).

•Activity state

–non-atomic

execution, ultim

ate

ly r

esult in s

om

e a

ction; a c

om

posite m

ade u

p o

f oth

er

activity/a

ction s

tate

s;

can b

e r

ep

resente

d b

y o

ther

activity d

iagra

ms

•Action state

–atomic

execution,

results in a

change in s

tate

of

the s

yste

m o

r th

e r

etu

rn o

f a

valu

e

(i.e

., c

alli

ng a

noth

er

ope

ration, se

ndin

g a

sig

nal, c

reating o

r destr

oyin

g a

n o

bje

ct, o

r som

e

com

puta

tion);

no

n-d

ecom

posable

actionstate

: Cer

tifica

teO

fOcc

upan

cy

[com

ple

ted]

objectflow

Se

lect

site

Com

mis

sio

n

arc

hite

ct

De

ve

lop

pla

n

Bid

pla

n

Do

site

wo

rkD

o t

rade

w

ork

()

Fin

ish

con

str

uction

initial state

sequential branch/decision

[not ac

cepte

d]

[els

e]

finalstate

concurrent fork

activity state with submachine

concurrentjoin

do c

onstr

uct(

)

Entr

y/ setL

ock()

triggerless transition

guard expression

No notational distinction between

action and activity states!

But, activity states can have certain

types of parts

op

tiona

l

0..*

AND

on

e in

com

ing,

se

ve

ral ou

tgo

ing

merge

(unbranch

) m

ultip

le in

com

ing, on

e o

utg

oin

g

(fo

r a

lte

rna

tive

th

read

s)OR

42

Sw

imla

nes &

Obje

ct F

low

Request service

Pay

Collect order

Take order

Deliver order

Fill order

Customer

Sales

Stockroom

Order

[placed]

Order

[filled]

Order

[entered]

Order

[delivered]

object flow ?

•Object flow

–o

bje

cts

conn

ecte

d u

sin

g a

dep

ende

ncy t

o t

he

activity or transition

that

cre

ate

s,

destr

oys,

or

mo

difie

s t

hem

•A

swimlane

is a

kin

d o

f packa

ge.

•E

very

activity b

elo

ngs t

o e

xactly o

ne s

wim

lan

e,

but

transitio

ns m

ay c

ross lanes.

swim

lane

What if using pins?

flow final

the p

rocess s

tops a

t th

is p

oin

t fo

r th

is

part

of th

e a

ctivity d

iagra

m

sub-activity indicator

43

Object Flows and Pins

A s

hort

hand n

ota

tion:

use inp

ut

pin

s a

nd o

utp

ut

pin

s (

para

mete

rs).

Invoic

e inv;

inv =

ne

w I

nvo

ice;

Fill

Ord

er(

inv);

44

A Sim

ple Example

–O

rder

Pro

cessin

g

<<

pre

conditio

n>

> O

rder

com

ple

te

<<

postc

onditio

n>

> O

rder

clo

sed

activity

para

mete

r

node =

obje

ct

node

What if using swimlanes?

merge

45

A Sim

ple Example

–O

rder

Pro

cessin

g Using sub-activity

Is this the same as the previous one?

46

POEmployee.sortMail

Activity Diagram even as M

ethod

POEmployee.deliverM

ail

POEmployee

sortMail()

deliverM

ail(k: Key) ad POEmployee.deliverM

ail

Check Out Truck

Put Mail in Boxes

ke

y

ad POEmployee.sort-deliverM

ail

47

Interruptible A

ctivity Region

•A

n interruptible activity region

surr

ounds a

gro

up o

f actions that can b

e

inte

rrupte

d.

•th

e P

rocess O

rder

action w

ill e

xecute

until com

ple

tion, th

en p

ass

contr

ol to

the C

lose O

rder

action, unle

ss a

Cancel R

equest in

terr

upt is

received w

hic

h w

ill p

ass c

ontr

ol to

the C

ancel O

rder

actio

n.

48

An Activity Diagram

–Distributing schedules

<<

sig

nal>

> redundant constr

ain

t

obje

ct

pin

parameter

htt

p:/

/ww

w.a

gile

mode

ling.c

om

/art

ifacts

/activityD

iagra

m.h

tm

hour-glass symbol represents time

send

receive

send

receive

49

Pins, Parameters, Effects

(ww

w.jo

t.fm

/issu

es/issu

e_

20

04_

01/c

olu

mn

3.p

df )

�effect

that th

eir a

ctions h

ave o

n o

bje

cts

that

move t

hro

ug

h t

he p

in:

one o

f th

e f

our

valu

es create, read, update, or delete

.

�T

ake O

rder

cre

ate

s a

n insta

nce o

f O

rder

and F

ill O

rder

rea

ds it.

�T

he create

eff

ect

is o

nly

possib

le o

n outputs

; and

the delete

eff

ect

is o

nly

possib

le o

n inputs

.

50

Multip

le T

okens

�O

bje

ct

nodes c

an h

old

more

than o

ne v

alu

e a

t a t

ime,

and s

om

e o

f th

ese v

alu

es c

an

be t

he s

am

e.

�Upper bound:

the m

axim

um

num

ber

of

toke

ns a

n o

bje

ct

no

de c

an h

old

, in

clu

din

gan

y

duplic

ate

valu

es.

�A

t ru

ntim

e,

wh

en t

he n

um

ber

of

valu

es in a

n o

bje

ct

no

de r

eaches

its u

pp

er

bound,

it

cannot

acce

pt

an

y m

ore

.

�If p

ain

ting is d

ela

yed t

oo m

uch f

or

som

e r

eason,

the input pin

will

reach its

uppe

r bound, and

part

s f

rom

polis

hin

g w

ill n

ot be a

ble

to m

ove d

ow

nstr

ea

m;

If p

ain

ting is d

ela

yed f

urt

he

r, th

e o

utp

ut

pin

of p

olis

hin

g w

ill fill

up a

nd the

polis

hin

g b

ehavio

r w

ill

not be a

ble

to

tra

nsfe

r ou

t polis

hed p

art

s;

Unle

ss the p

olis

hin

g b

ehavio

r has a

n o

bje

ct node in

tern

al to

it th

at buff

ers

outp

ut

part

s,

it w

ill n

ot

be a

ble

to take p

art

s f

rom

its

input pin

, w

hic

h w

ill lik

ew

ise fill

up a

nd p

ropaga

te the

backup; O

nly

when t

he input pin

to P

AIN

T g

oes b

elo

w its

upper

bo

und w

ill p

art

s b

e a

ble

to flo

w a

gain

.

51

Multiple Tokens -Ord

ering

•O

bje

ct nodes h

old

ing m

ultip

le v

alu

es c

an s

pecify the order

in w

hic

h

valu

es m

ove d

ow

nstr

eam

.

•T

he d

efa

ult is F

IFO

(a p

ipe);

users

can c

hange this

to L

IFO

(a q

ueue),

or

specify their o

wn b

ehavio

r to

sele

ct w

hic

h v

alu

e is p

assed o

ut firs

t.

Non-D

eterm

inism

(htt

p://w

ww

.jot.

fm/issues/issue

_2

004

_0

1/c

olu

mn3

.pd

f)

52

Parameter Multiplicity & O

bject Flow W

eight

•Minimum multiplicity

on a

ninput

para

mete

r m

eans a

be

ha

vio

r or

opera

tio

n

cannot

be invo

ked b

y a

n a

ctio

n u

ntil th

e n

um

ber

of

valu

es a

vaila

ble

at

each o

f its

input

pin

s r

eaches t

he m

inim

um

for

the c

orr

espond

ing p

ara

mete

r, w

hic

h m

ight

be z

ero

�W

eig

ht

on o

bje

ct

flo

w e

dg

es s

pecifie

s t

he m

inim

um

num

ber

of

valu

es t

hat

can t

ravers

e a

n o

bje

ct

flo

w e

dge a

t one t

ime.

53

Inte

raction O

verv

iew

Dia

gra

ms

Behavio

ral D

iagra

ms

–U

se c

ase

–S

tate

chart

–A

ctivity

Inte

raction D

iagra

ms

–S

equence;

Com

munic

ation

–Interaction

Overview

–T

imin

g

54

Interaction O

verview Diagram

(htt

p:/

/ww

w.a

gile

mode

ling.c

om

/art

ifa

cts

/in

tera

ction

Ove

rvie

wD

iagra

m.h

tm)

�variants

on U

ML

activity d

iagra

ms

whic

h o

verv

iew

contr

ol flow

.

�T

he n

odes w

ithin

the d

iagra

m a

re frames, not activitie

s

�T

wo

types o

f fr

am

e s

how

n:

�in

tera

ction f

ram

es d

epic

ting a

ny t

ype

of

UM

L inte

raction d

iagra

m (

sequence d

iagra

m: sd

,

com

munic

ation d

iagra

m: cd,

tim

ing d

iagra

m: td

, in

tera

ction o

verv

iew

dia

gra

m: iod

)

�in

tera

ction o

ccurr

ence f

ram

es (ref;

typic

ally

anon

ym

ous)

whic

h indic

ate

an a

ctivity o

r

opera

tion to

invoke.

sd E

nro

ll in

Sem

inar

lif

elin

es :

Stu

dent :S

em

inar

:Cours

e :E

nro

llment

:Stu

dent

:Sem

inar

:Cours

e

ref

Select Seminar()

ge

tPre

req (

)is

Elig

ible

(std

)

sd D

ete

rmin

e E

ligib

ility

{0..7m

sec}

[not elig

ible

]

:Sem

inar

:Enro

llment

Num

be

r e

nro

lled

cd D

ete

rmin

e S

eat A

vaila

bili

ty

ref

AddToWaitingList()

ref

Enroll in Seminar()

[seat availa

ble

]

[no s

eat]

55

sd W

ithdra

wal

:User

:AT

M:B

ank

ref

Authenticate

PIN O

KPIN NOK

with

dra

w

msg (

“am

oun

t”)

am

oun

t (a

)ch

kA

cct

(a)

msg (

“ca

rd”)

msg (

“ille

gal en

try”)

no

t enou

gh

ba

lm

sg(“

am

oun

t to

o b

ig”)

Interaction O

verview Diagram

:User

:AT

M:B

ank

sd

:User

:AT

M

sd

:User

:AT

M

sd

en

ou

gh

ba

lm

one

y

rece

ipt

:User

:AT

M:B

ank

sd

sd

Relationship with Sequence Diagram?

56

Tim

ing D

iagra

ms

Behavio

ral D

iagra

ms

–U

se c

ase

–S

tate

chart

–A

ctivity

Inte

raction D

iagra

ms

–S

equence;

Com

munic

ation

–In

tera

ction O

verv

iew

–Timing

57

Inte

raction D

iagra

m: T

imin

g D

iagra

m�

To

exp

lore

th

e b

eh

avio

rs o

f 0

..*

obje

cts

th

rou

gh

ou

t a

giv

en

pe

rio

d

of

tim

e.

�T

wo

ba

sic

fla

vo

rs:

concise

no

tatio

n a

nd

ro

bu

st

no

tatio

n

The lifecycle of a single seminar

�T

he c

ritical sta

tes

–Proposed, Scheduled

, Enrolling Students

, Being Taught,

Final Exams, Closed

�T

he t

wo lin

es s

urr

oundin

g the s

tate

s a

re c

alle

d a

genera

l valu

e lifelin

e.

�W

hen the

tw

o lin

es c

ross o

ne a

no

ther

it indic

ate

s a

transition point

betw

een

sta

tes.

�Timing constraints

alo

ng the b

otto

m o

f th

e d

iagra

m,

indic

ating the p

eriod o

f tim

e d

uring w

hic

h the s

em

ina

r is

in

each s

tate

.

critical

sta

tes

Timing

constraints

58

htt

p:/

/ww

w.v

isu

al-para

dig

m.c

om

/hig

hlig

ht/

hig

hlig

htu

ml2

supp

ort

.jsp

Interaction Diagram: Tim

ing Diagram (robust notation)

timing ruler w. tick marks

states

state timeline

transition point

Can you transform this into a concise notation?

59

Appendix

: M

iscella

neous

60

Role Names

61

Iterative M

essages

[Cra

ig L

arm

an] [h

ttp

://w

ww

.phptr

.co

m/a

rtic

les/a

rtic

le.a

sp?p

=3

6044

1&

se

qN

um

=6&

rl=

1]

62

Polymorphic M

essage

[Cra

ig L

arm

an] [h

ttp

://w

ww

.phptr

.co

m/a

rtic

les/a

rtic

le.a

sp?p

=3

6044

1&

se

qN

um

=6&

rl=

1]

63

Sequence Diagram Shapes

64

65

Race conditions

�E

.g. an o

bje

ct re

ceiv

es t

wo m

essages

�O

rder

of arr

ival changes b

ehavio

ur

�O

nly

one o

rder

leads to c

orr

ect behavio

ur

�C

ellu

larR

adio

expects

Answ

er(

) not C

onnect(

pno)

�T

wo s

tate

s w

hen S

end c

an b

e p

ressed

�T

o m

ake o

utg

oin

g c

all

(after

dia

lling d

igits)

�T

o a

nsw

er

incom

ing c

all

�S

tate

dia

gra

m c

an b

e u

sefu

l here

�T

o h

elp

realiz

e there

is a

race c

onditio

n

�T

o s

pecify w

hat should

happen

�A

ngle

d a

rrow

s-

Show

message d

ela

y

•D

iale

r: g

ath

er

dig

its, em

it tones

•C

ellu

lar

Radio

: com

munic

ate

with c

ellu

lar

netw

ork

•B

utton, S

peaker,

Mic

rophone, D

ispla

y h

ard

ware

66

67

Sequence Diagram -

Reference

(ww

w.c

s.t

ut.

fi/ta

pa

htu

mat/

olio

200

4/r

ich

ard

son.p

df)

68

Verify

Card

acceptC

ard

Rele

aseC

ard

Verify

Tra

nsaction

outO

fServ

ice

rele

aseC

ard

OutO

fServ

ice

AT

M

{final}

{final}

{final}{final}

ReadA

mount

sele

ctA

mou

nt

am

ount

State M

achine Redefinition

ente

rAm

ou

nt

ok

reje

ct

{extended

}

oth

erA

moun

t

{extended

}

Fle

xib

leA

TM

69

Inte

raction

Dia

gra

m:

Tim

ing

Dia

gra

m (

rob

ust

no

tatio

n)

A frame to bound the two lifelines

states/conditions

events/stimuli

transition point

message

state timeline

state timeline timing ruler w. tick marks

timing constraint

timing observation

70

Tim

ing

Dia

gra

m –

anoth

er

exam

ple

(ww

w.c

s.t

ut.

fi/t

ap

ah

tum

at/o

lio20

04

/ric

ha

rdson

.pdf)

71

_tim

ing

?tim

eo

ut

^_tx

port

!data

0

_timing: interface/connection

?: receive

timeout: event

^: send

_txport: interface/connection

!: send

data0: event

+: multiple receive

“:”: multiple send

Real-Tim

e Extensions: Using CCS