state activity diagram

8/11/2019 State Activity Diagram

1/91

State & Activity Diagram

copyright 2001 SNU OOPSLA Lab.


2/91

ContentsPart1. State Diagram

asic State !achine Concepts Statecharts an" Ob#ects

A"vance" !o"e$ing Concepts

Case St%"y


3/91

Net s$i"es are



Case St%"y


4/91

ON

A%tomata

A machine 'hose o%tp%t behavior is not on$y a "irectconse(%ence o) the c%rrent inp%t* b%t o) some past

history o) its inp%ts

Characteri+e" by an interna$ state 'hich represents thispast eperience

ONON ON

OFF


5/91

off

on

State !achine ,A%tomaton- Diagram

raphica$ ren"ering o) a%tomata behavior

Lamp On

Lamp Off

off

on


6/91

O%tp%ts an" Actions As the a%tomaton changes state it can

generate o%tp%ts/on

off

Lamp Onprint(on)

LampOff

off

on

Mooreautomaton

on

off

Lamp On

LampOff

off

on/print(on)

Mealyautomaton


7/91

ten"e" State !achines

A""ition o) variab$es ,eten"e" state-

off

on

Lamp On

Lamp Off

off

on/ctr := ctr + 1

ctr : Integer


8/91

A it o) heory

An eten"e" ,!ea$y- state machine is "e)ine" by/ a set o) inp%t signa$s ,inp%t a$phabet-

a set o) o%tp%t signa$s ,o%tp%t a$phabet-

a set o) states

a set o) transitions

triggering signa$

action

a set o) eten"e" state variab$es

an initia$ state "esignation

a set o) )ina$ states ,i) terminating a%tomaton-


9/91

top

asic U!L Statechart Diagram

Ready

stop

/ctr := 0stop

State

Trigger

Action

Initialpseudostate

Transition

Finalstate

Done

top state


10/91

hat 3in" o) ehavior4

5n genera$* state machines are s%itab$e )or"escribing event6"riven* "iscrete behavior

inappropriate )or mo"e$ing contin%o%s behavior

time

threshold


11/91

vent6Driven ehavior

vent 7 a type o) observab$e occ%rrence interactions/

synchrono%s ob#ect operation invocation ,ca$$ event-

asynchrono%s signa$ reception ,signa$ event-

occ%rrence o) time instants ,time event- interva$ epiry

ca$en"ar8c$oc9 time

change in va$%e o) some entity ,change event-

vent 5nstance 7 an instance o) an event ,type- occ%rs at a partic%$ar time instant an" has no "%ration


12/91

he ehavior o) hat4

5n princip$e* anything that mani)ests event6"rivenbehavior N/ there is no s%pport c%rrent$y in U!L )or mo"e$ing contin%o%s

behavior

5n practice/ the behavior o) in"ivi"%a$ ob#ects

ob#ect interactions

he "ynamic semantics o) U!L state machines arec%rrent$y main$y speci)ie" )or the case o) active

ob#ects


13/91

Net s$i"es are



Case St%"y


14/91

Statecharts

U!L %ses an ob#ect6oriente" variant o) :are$sstatecharts a"#%ste" to so)t'are mo"e$ing nee"s

Use" to mo"e$ event6"riven ,reactive- behavior 'e$$6s%ite" to the server mo"e$ inherent in the ob#ect para"igm

Primary %se )or mo"e$ing the behavior o) activeevent6"riven ob#ects systems mo"e$e" as net'or9s o) co$$aborating state machines

r%n6to6comp$etion para"igm signi)icant$y simp$i)ies conc%rrencymanagement


15/91

Statecharts ,cont"-

5nc$%"es a n%mber o) sophisticate" )eat%res thatrea$i+e common state6machine %sage patterns/ entry8eit actions

state activities

"ynamic an" static con"itiona$ branching

A$so* provi"es hierarchica$ mo"e$ing )or "ea$ing 'ith

very comp$e systems

hierarchica$ states hierarchica$ transitions

orthogona$ity


16/91

hat is a State

A state "iagram may have astarting point,so$i"circ$e- an" severa$ end points ,b%$$s eyes-.

Astateis sho'n as a ro%n"e" rectang$e.

ach state has a name* optiona$$y state variab$es,i.e.* attrib%tes o) the state6o'ning c$ass-* an"optiona$$y activities.

Stan"ar" events in the activity compartment

inc$%"e entry* exit* an" do.Name

Statevariables

Activities


17/91

State ransition

Transitionsbet'een states are sho'n as arro's. ;or9 an" #oin%sing the synch. bar are a$$o'e".

A transition can be $abe$e" 'ith an eventthat ca%ses it.hen an event occ%rs* the transition )rom one state to

another fires.

5) no event is speci)ie"* the transition 'i$$ )ire 'hen interna$actions o) the so%rce state are eec%te".


18/91

State ransition

Synta/ event-name ,parameters -


19/91

State Diagram


20/91

Ob#ect ehavior 6 enera$ !o"e$

Simp$e server mo"e$/

HandleRequest

Initialize

Object

TerminateObject

Wait forRequestWait forRequest

void:offHook ();{busy = true;obj.reqDialtone();

};

Handling depends onspecific request type


21/91

Direct mapping/

HandleEvent

InitializeObject

TerminateObject

Wait forEvent

on

off

Lamp On

Lamp

Off

offon/print(on)

stop

Ob#ect ehavior an" State !achines


22/91

HandleRequest

Initialize

Object

Terminate

Object

Wait forRequest

HandleRequest

Initialize

Object

Terminate

Object

Wait forRequest

Ob#ect an" hrea"s

Passive objects:depend on external power (thread ofexecution Active objects:self!powered (own thread of execution


23/91

Passive Ob#ects/ Dynamic Semantics

"ncapsulation does not protect the ob#ect from concurrenc$

conflicts%

"xplicit s$nchroni&ation is still re'uired

Handle

Request

InitializeObject

TerminateObject

Wait forRequest


24/91

anActiveObject

#currentEvent : Event

+ start ( )+ poll ( )+ stop ( )

Active Ob#ects an" State !achines Ob#ects that encaps%$ate o'n threa" o)

eec%tion

created

ready

start/^master.ready()

poll/^master.ack()

stop/

poll/defer

ready

created

start start/^master.ready() ready


25/91

Active Ob#ects/ Dynamic Semantics

Run-to-completion model:seriali&ed event handlineliminates internal concurrenc$minimal context switchin overhead

ActiveObject:


26/91

Active1Active1 Active2Active2

he ?%n6to6Comp$etion !o"e$

A high priority event )or ,another- active ob#ect 'i$$preempt an active ob#ect that is han"$ing a $o'6priorityevent

hi

hi

lo


27/91

Next slides are



Case St%"y


28/91

State ntry an" it Actions

A "ynamic assertion mechanism

LampOnentry/lamp.on();

exit/lamp.off();

e1

e2


29/91

Resulting action sequence:printf(exiting);printf(to off);

lamp.off();

Or"er o) Actions/ Simp$e Case

it actions pre)i transition actions

ntry action post)i transition actions

printf(exiting);

printf(needless);

lamp.off();

off/printf(needless);

off/printf(to off);LampOff

entry/lamp.off();

exit/printf(exiting);

LampOn

entry/lamp.on();exit/printf(exiting);


30/91

5nterna$ ransitions

Se$)6transitions that bypass entry an" eitactions

LampOffentry/lamp.off();

exit/printf(exiting);

off/null;

Internal transitiontriggered byan off event


31/91

Error

entry/printf(error!)

State ,Do- Activities

;or9s a conc%rrent threa" that eec%tes %nti$/ the action comp$etes or

the state is eite" thro%gh an o%tgoing transition

do/while (true) alarm.ring();

do activity


32/91

%ar"s Con"itiona$ eec%tion o) transitions

g%ar"s ,oo$ean pre"icates- m%st be si"e6e))ect )ree

Selling

Unhappy

Happy

bid [(value >= 100) & (value < 200)]/sell

bid [value >= 200]/sell

bid [value < 100]/reject


33/91

Static Con"itiona$ ranching !ere$y a graphica$ shortc%t )or convenient

ren"ering o) "ecision trees

[(value >= 100) & (value < 200)]/sell

[value >= 200]/sell

[value < 100]/reject

Selling

Unhappy

Happy

bid


34/91

bid /gain := calculatePotentialGain(value)

Selling

Unhappy

Happy

Dynamic Con"itiona$ ranching

Choice pse%"ostate/ g%ar"s are eva$%ate" at the

instant 'hen the "ecision point is reache"

[(gain >= 100) & (gain < 200)]/sell

[gain >= 200]/sell

[gain < 100]/reject

Dynamicchoicepoint


35/91

:ierarchica$ State !achines

ra"%ate" attac9 on comp$eity

states "ecompose" into state machines

LampFlashingflash/

1sec/

1sec/

FlashOff

entry/lamp.off()

FlashOn

entry/lamp.on()off/

LampOff

entry/lamp.off()

LampOn

entry/lamp.on()

on/

on/

on/


36/91

St%bNotation Notationa$ shortc%t/ no semantic signi)icance

LampFlashingflash/

on/

FlashOn

FlashOff

off/

LampOff

entry/lamp.off()

LampOn

entry/lamp.on()

on/ on/


37/91

LampFlashing

1sec/1sec/

FlashOffentry/lamp.off()

FlashOn

entry/lamp.on()off/

LampOff

entry/lamp.off()

LampOn

entry/lamp.on()

on/

ro%p ransitions

:igher6$eve$ transitionsflash/

on/

Default transition tothe initial pseudostate

Group transition


38/91

Comp$etion ransitions riggere" by a comp$etion event

generate" a%tomatica$$y 'hen an imme"iate$y neste" statemachine terminates

Committing

Phase1

Phase2 CommitDone

completiontransition (no trigger)


39/91

LampFlashing

off/

FlashOff

FlashOn

riggering ?%$es 'o or more transitions may have the same event

trigger innermost transition ta9es prece"ence

event is "iscar"e" 'hether or not it triggers a transition

on/on/


40/91

De)erre" vents

vents can be retaine" i) they "o not trigger a

transition

off/

LampOn

entry/lamp.on()

on/

LampOff

entry/lamp.off()

off/defer

Deferred event


41/91

Or"er o) Actions/ Comp$e Case

Same approach as )or the simp$e case

S1exit/exS1

S11exit/exS11

S2entry/enS2

S21entry/enS21

initS2E/actE

Actions execution sequence:

exS11exS1 actEenS2 initS2 enS21


42/91

suspend/

:istory

?et%rn to a previo%s$y visite" hierarchica$ state

"eep an" sha$$o' history options

Diagnosing

Diagnostic1

Step11

Step12

Diagnostic2

Step21

Step22resume/H*


43/91

Orthogona$ity !%$tip$e sim%$taneo%s perspectives on the same entity

Child

Adult

Retiree

age

Poor

Rich

financialStatus


44/91

Orthogona$ ?egions Combine m%$tip$e sim%$taneo%s "escriptions

Child

Adult

Retiree

age

Poor

Rich

financialStatus

Poor

Rich

financialStatus

Child

Adult

Retiree

age


45/91

Outlaw

LawAbiding Poor

Rich

financialStatuslegalStatus

Orthogona$ ?egions 6 Semantics A$$ m%t%a$$y orthogona$ regions "etect the same events

an" respon" to themsim%$taneo%s$y %s%a$$y re"%ces to inter$eaving o) some 9in"

robBank/ robBank/


46/91

Catch22

sanityStatus flightStatus

5nteractions et'een ?egions ypica$$y thro%gh share" variab$es or a'areness o)

other regionsstate changes

(flying)/

Crazyentry/sane := false;

Saneentry/sane := true;

requestGrounding/

Flyingentry/flying := true;

Groundedentry/flying := false;

(sane)/

(~sane)/

sane : Boolean

flying : Boolean


47/91

ransition ;or9s an" @oins ;or transitions into8o%t o) orthogona$ regions/

StaffMember

employee

Child Adult Retiree

age

Manager


48/91

Common !is%se o) Orthogona$ity Using regions to mo"e$ in"epen"ent ob#ects

Child

Adult

Retiree

Child

Adult

Retiree

Person1 Person2

Person1 Person2


49/91

Net s$i"es are asic State !achine Concepts

Statecharts an" Ob#ects


Case St%"y


50/91

line card 1

line card NEnd user

unreliable

telecom lines

Case St%"y/ Protoco$ :an"$er

A m%$ti6$ine pac9et s'itch that %ses the

a$ternating6bit protoco$ as its $in9 protoco$

SWITCH

.

.

.

AB

sender

ABreceiver

End user

End user

ABsender

ABreceiver

AB protocol


51/91

packetizer

unpackerReceiverSender

A$ternating it Protoco$ ,1- A simp$e one6'ay point6to6point pac9et protoco$

data(1)

ackA

pktAdata(1)

ack

ack

data(2)

ackB

pktBdata(2)

ack

ack

etc.

AB protocol


52/91

A$ternating it Protoco$ ,2- State machine speci)ication

ackB/âckdata/^pktA

ackA/âck data/^pktB

timeout/^pktB

timeout/^pktA

Sender SMAcceptPktA

WaitAckA

AcceptPktB

WaitAckB

pktA/^data

ack/âckA

pktB/^dataack/âckB

timeout/âckB

timeout/âckA

RcvdPktA

WaitPktB

RcvdPktB

WaitPktA

Receiver SM


53/91

A""itiona$ Consi"erations

S%pport ,contro$- in)rastr%ct%re

SWITCH

ABreceiver

ABsender

operatorinterface

DBinterface

Systemoperator

DBase

AB linesmanager


54/91

Contro$

The set of (additional) mechanisms and actionsrequired to ring a system into the desired

operational state and to maintain it in that state inthe face of various planned and unplanned

disruptions )or software s$stems this includes*

s$stem+component start!up and shut!down failure detection+reportin+recover$ s$stem administration, maintenance, and provisionin (on!line software uprade


55/91

?etro)itting Contro$ ehavior

AcceptPktA

WaitAckA

AcceptPktB

WaitAckB

Failed

JustCeated!ad"ae

Audit

#ettin$%ata

&ead'(o#o

Anal'sin$

Failue


56/91

he Contro$ A%tomaton 5n iso$ation* the same contro$ behavior appears m%ch

simp$er

Failed

JustCeated

!ad"ae

Audit

#ettin$%ata

&ead'(o#o

Anal'sin$

Failue

Opeational


57/91

p$oiting 5nheritance

Abstract contro$ c$asses can capt%re thecommon contro$ behavior

AbstractController

Sender Receiver . . .


58/91

Failed

JustCeated

!ad"ae

Audit

#ettin$%ata

&ead'(o#o

Anal'sin$

Failue

Opeational

p$oiting :ierarchica$ StatesAbstractController

Sender


59/91

Activity Diagrams


60/91

Activity Diagram App$ications

5nten"e" )or app$ications that nee" contro$ )$o' orob#ect8"ata )$o' mo"e$s

... rather than event6"riven mo"e$s $i9e state

machines.

;or eamp$e/ b%siness process mo"e$ing an"'or9)$o'.

he "i))erence in the three mo"e$s is ho' step in a

process is initiate"* especia$$y 'ith respect to ho' thestep gets its inp%ts.


61/91

Contro$ ;$o'

ach step is ta9en 'hen the previo%s one )inishes

regar"$ess o) 'hether inp%ts are avai$ab$e* acc%rate*or comp$ete ,p%$$-.

mphasis is on or"er in 'hich steps are ta9en.

Not UMLNotation!

Chart Course Cancel Trip

Analyze Weather Info

Weather InfoStart


62/91

Ob#ect8Data ;$o'

ach step is ta9en 'hen a$$ the re(%ire" inp%t ob#ects8"ata are avai$ab$e

an" on$y 'hen a$$ the inp%ts are avai$ab$e ,p%sh-.

mphasis is on ob#ects )$o'ing bet'een steps.

Design Product

ProcureMaterials

Acquire Capital

BuildSubassembly 1

BuildSubassembly 2

Final

Assembly

Not UML

Notation


63/91

State !achine

ach step is ta9en 'hen events are "etecte" by themachine

%sing inp%ts given by the event.

mphasis is on reacting to environment.

Ready To Start

Coin Deposited

Ready For Order

Selection Made

DispenseProduct

ReturnChange

Cancel ButtonPressed

Not UML

Notation


64/91

C%rrent$y activity graphs are mo"e$e" as a 9in"o) state machine.

!o"e$er "oesnt norma$$y nee" to be a'are o)

this s$eight6o)6han" ... ... b%t 'i$$ notice that BstateB is %se" in the

e$ement names.

Activity graphs 'i$$ become in"epen"ent o)state machines in U!L 2.0.

Activity Diagrams ase" on State !achines


65/91

@%st $i9e their state machine co%nterparts ,simp$estate an" s%bmachine state- ecept that ...

... transitions coming o%t o) them are ta9en 'hen the

step is )inishe"* rather than being triggere" by a

eterna$ event* ...

... an" they s%pport "ynamic conc%rrency.

Action Action (State

Subactivity Subactivit$ (State

3in"s o) Steps in Activity Diagrams


66/91

Action ,State-

An action is %se" )or anything that "oes not "irect$ystart another activity graph* $i9e invo9ing an operationon an ob#ect* or r%nning a %ser6speci)ie" action.

:o'ever* an action can invo9e an operation that has

another activity graph as a metho" ,possib$e

po$ymorphism-.

Action


67/91

S%bactivity ,State-

A s%bactivity ,state- starts another activity graph

'itho%t %sing an operation.

Use" )or )%nctiona$ "ecomposition* non6po$ymorphicapp$ications* $i9e many 'or9)$o' systems.

he invo9e" activity graph can be %se" by many

s%bactivity states.

Subactivity


68/91

amp$e

POEmployee.sortMail Deliver Mail

POEmployee

sortMail() Check Out

Truck

Put Mail

In Boxes

Deliver Mail


69/91

POEmployee

sortMail()

Activity raph as !etho"

App$ication is comp$ete$y OO 'hen a$$ action states invo9eoperations

A$$ activity graphs are metho"s )or operations.

POEmployee.sortMail POEmployee.deliverMail

deliverMail()realize

Check OutTruck

Put MailIn Boxes

PO Employee Deliver Mail Method


70/91

Dynamic conc%rrency

App$ies to actions an" s%bactivities.

Not inherite" )rom state machines.

5nvo9es an action or s%bactivity any n%mber o) times in

para$$e$* as "etermine" by an epression eva$%ate" at

r%ntime. pression a$so "etermines arg%ments. Upper right6han" corner sho's a m%$tip$icity restricting the

n%mber o) para$$e$ invocations.

O%tgoing transition triggere" 'hen a$$ invocations are "one. C%rrent$y no stan"ar" notation )or conc%rrency epression

or ho' arg%ments are accesse" by actions. Attach a note

as 'or9aro%n" )or epression. 5ss%e )or U!L 2.0.

Action/Subactivity *


71/91

Ob#ect ;$o' ,State-

A specia$ sort o) step ,state- that represents the

avai$abi$ity o) a partic%$ar 9in" o) ob#ect* perhaps in a

partic%$ar state.

No action or s%bactivity is invo9e" an" contro$ passes

imme"iate$y to the net step ,state-.

P$aces constraints on inp%t an" o%tp%t parameters o)steps be)ore an" a)ter it.

Class

[State]


72/91

Ob#ect ;$o' ,State-

a9e Or"er m%st have an o%tp%t parameter givingan or"er* or one o) its s%btypes.

;i$$ Or"er m%st have an inp%t parameter ta9ing anor"er* or one o) its s%pertypes.

Dashe" $ines %se" 'ith ob#ect )$o' have the samesemantics as any other state transition.

Order

[Taken]

Take Order Fill Order


73/91

Coor"inating Steps

-nitial state

)inal state

)or. and #oin

-nherited from state machines


74/91

Decision point an" merge , - are inherite")rom state machines.

;or mo"e$ing conventiona$ )$o' chart "ecisions.

Coor"inating Steps

CalculateCost ChargeAccount

GetAuthorization

[cost < $50]

[cost >= $50]


75/91

Synch state , - is inherite" )rom state machines b%t %se"

most$y in activity graphs. Provi"es comm%nication capabi$ity bet'een para$$e$

processes.

Coor"inating Steps

State machine

notation

InspectInstall

Foundation

BuildFrame

InstallElectricity

in Foundation

PutOn

Roof

InstallElectricityIn Frame

InstallElectricityOutside

InstallWalls

* *


76/91

;or9s an" #oins "o not re(%ire composite states.

Synch states may be omitte" )or the common case,%n$imite" bo%n" an" one incoming an" o%tgoing

transition-.

BuildFrame

Install

Foundation

InstallElectricity

in Foundation

PutOn

Roof

InstallElectricityIn Frame

InstallElectricityOutside

InstallWalls

Inspect

Activity diagramnotation

Convenience ;eat%res ,Synch State-


77/91

Ob#ect )$o' states can be synch states

Obj[S2]

A11 A12 A13

A21 A22 A23

Convenience ;eat%res ,Synch State-


78/91

Convenience ;eat%res ;or9 transitions can have g%ar"s.

RegisterBug

EvaluateImpact

FixBug

RevisePlan

ReleaseFix

TestFix

[ priority = 1]

RegisterBug

Evaluate

Impact

Fix

Bug

Revise

Plan

ReleaseFix

Test

Fix

[ priority = 1]

[else]

-nstead of doin this*


79/91

Convenience ;eat%res Partitions are a gro%ping mechanism.

S'im$anes are the notation )or partitions.

hey "o not provi"e "omain6speci)ic semantics.

oo$s can generate s'im$ane presentation )rom "omain6

speci)ic in)ormation 'itho%t partitions.

RegisterBug

EvaluateImpact

FixBug

RevisePlan

ReleaseFix

TestFix

[ priority = 1]

Management

Support

Engineering


80/91

Convenience ;eat%res Sinal send icon

Signal

CoffeePot

Wake Up

Get Cups

Turn on Coffee Pot

Coffee Done

Drink Coffee

Signal

translates to a transition with asend action/

Sinal receipt icon

translates to a wait state (astate with no action and a sinaltrier event/


81/91

hen to Use Activity Diagrams

Use activity "iagrams 'hen the behavior yo%

are mo"e$ing ... "oes not "epen" m%ch on eterna$ events.

most$y has steps that r%n to comp$etion* rather than

being interr%pte" by events. re(%ires ob#ect8"ata )$o' bet'een steps.

is being constr%cte" at a stage 'hen yo% are moreconcerne" 'ith 'hich activities happen* rather than

'hich ob#ects are responsib$e )or them ,eceptpartitions possib$y-.


82/91

Activity Diagram !o"e$ing ips

Contro$ )$o' an" ob#ect )$o' are not separate.

oth are mo"e$e" 'ith state transitions.

Dashe" ob#ect )$o' $ines are a$so contro$ )$o'.

o% can mi state machine an" contro$8ob#ect)$o' constr%cts on the same "iagram ,tho%gh

yo% probab$y "o not 'ant to-.


83/91


RequestReturn

Get ReturnNumber

Ship Item

Item[returned]

ReceiveItem

RestockItem

CreditAccount

Item[available]

Customer

Telesales

Warehouse

Accounting

From UML

User Guide:

Customer Telesales WarehouseAccounting


84/91

Activit

y!o"e$ing1ips

Request

Return

Get ReturnNumber

Ship Item

Item[returned]

ReceiveItem

RestockItem

CreditAccount Item

[available]


85/91


Activity "iagrams inherit )rom state machines the

re(%irement )or 'e$$6str%ct%re" nesting o) composite states.

his means yo% sho%$" either mo"e$ as i) composite states'ere there by matching a$$ )or9s8"ecisions 'ith a

correspon" #oin8merges

or chec9 that the "iagram can be trans$ate" to one thatis 'e$$6neste".

his ins%res that "iagram is eec%tab$e %n"er state machinesemantics.


86/91

Activity Diagram !o"e$ing ipsWell-nested:

ti it i " $i i


87/91

Not well-nested:


Apply structured coding principles. (Be careful with gotos!)

A ti it Di ! " $i i


88/91


Can be translated to well-nested

diagram on earlier slide:

amp$e / Login o) an on$ine ban9ing


89/91

system

Activity

di


90/91

diagram

withdrawmoney

(ATM)

U A ti it Di


91/91

rap Up/ Activity Diagrams

Use Activity Diagrams )or app$ications that are primari$y

contro$ an" "ata6"riven* $i9e b%siness mo"e$ing rather than event6"riven app$ications $i9e embe""e"

systems.

Activity "iagrams are a 9in" o) state machine %nti$ U!L 2.0 so contro$ an" ob#ect8"ata )$o' "o not have separate

semantics.

U!L 1. has ne' )eat%res )or b%siness mo"e$ing thatincrease po'er an" convenience. Chec9 it o%t an" give

)ee"bac9E

state activity diagram

Documents