State & Activity Diagram

copyright 2001 SNU OOPSLA Lab.

Contents Part1. State Diagram
asic State !achine Concepts
Statecharts an" Ob#ects
A"vance" !o"e$ing Concepts
Case St%"y
Ne&t s$i"es are
asic State !achine Concepts
Statecharts an" Ob#ects
A"vance" !o"e$ing Concepts
Case St%"y


ON
A%tomata
A machine 'hose o%tp%t behavior is not on$y a "irect
conse(%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 this
past e&perience
ON ON ON
OFF
off
on
State !achine ,A%tomaton- Diagram
.raphica$ ren"ering o) a%tomata behavior

Lamp On


Lamp Off

off
on
O%tp%ts an" Actions
As the a%tomaton changes state it can
generate o%tp%ts/
on
off
Lamp On
print(on)
Lamp
Off
off
on
Moore automaton
on
off
Lamp On
Lamp
Off
off
on/print(on)
Mealy automaton
0&ten"e" State !achines
A""ition o) variab$es ,e&ten"e" state-
off
on

Lamp On


Lamp Off

off
on/ctr := ctr + 1
ctr : Integer
A it o) 1heory
An e&ten"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) e&ten"e" state variab$es
an initia$ state "esignation
a set o) )ina$ states ,i) terminating a%tomaton-
top
asic U!L Statechart Diagram
Ready
stop
/ctr := 0 stop
State
Trigger
Action
Initial
pseudostate
Transition
Final
state
Done
top state
2hat 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
0vent6Driven ehavior
0vent 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$ e&piry
ca$en"ar8c$oc9 time
change in va$%e o) some entity ,change event-
0vent 5nstance 7 an instance o) an event ,type-
occ%rs at a partic%$ar time instant an" has no "%ration
1he ehavior o) 2hat4
5n princip$e* anything that mani)ests event6"riven
behavior
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
1he "ynamic semantics o) U!L state machines are
c%rrent$y main$y speci)ie" )or the case o) active
ob#ects
Ne&t s$i"es are
asic State !achine Concepts
Statecharts an" Ob#ects
A"vance" !o"e$ing Concepts
Case St%"y

Statecharts
U!L %ses an ob#ect6oriente" variant o) :are$s
statecharts
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) active
event6"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%rrency
management
Statecharts ,cont"-
5nc$%"es a n%mber o) sophisticate" )eat%res that
rea$i+e common state6machine %sage patterns/
entry8e&it 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
2hat is a State
A state "iagram may have a starting point ,so$i"
circ$e- an" severa$ end points ,b%$$s eyes-.
A state is sho'n as a ro%n"e" rectang$e.
0ach 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
State
variables
Activities
State 1ransition
Transitions bet'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 event that ca%ses it.
2hen 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 e&ec%te".
State 1ransition
Synta&/
event-name , parameters - <guard condition= 8 action expressions
An event can be one o) the )o$$o'ing cases/
A message is receive" )rom another ob#ect ,or the ob#ect itse$)-
A speci)ie" time has passe"> e.g.* after,2 seconds-
1here has been a change in some state> e.g.* when,quantity < 10-
2hen a g%ar" con"ition is speci)ie"* the event m%st occ%r an"
the con"ition be tr%e )or the transition to )ire.
Action e&pressions are 'ritten in terms o) operations an"
attrib%tes o) the o'ning c$ass ,the c$assi)ier- an"8or 'ith
parameters o) the event.

State Diagram
Ob#ect ehavior 6 .enera$ !o"e$
Simp$e server mo"e$/
Handle
Request
Initialize
Object
Terminate
Object
Wait for
Request
Wait for
Request
void:offHook ();
{busy = true;
obj.reqDialtone();

};
Handling depends on
specific request type
Direct mapping/
Handle
Event
Initialize
Object
Terminate
Object
Wait for
Event
on
off
Lamp On
Lamp
Off
off
on/print(on)
stop
Ob#ect ehavior an" State !achines
Handle
Request
Initialize
Object
Terminate
Object
Wait for
Request
Handle
Request
Initialize
Object
Terminate
Object
Wait for
Request
Ob#ect an" 1hrea"s
Passive objects: depend on external power (thread of
execution
Active objects: self!powered (own thread of execution

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
Initialize
Object
Terminate
Object
Wait for
Request
anActiveObject
#currentEvent : Event
+ start ( )
+ poll ( )
+ stop ( )
Active Ob#ects an" State !achines
Ob#ects that encaps%$ate o'n threa" o)
e&ec%tion
created
ready
start/^master.ready()
poll/^master.ack()
stop/
poll/defer
ready
created
start
start/^master.ready()
ready
Active Ob#ects/ Dynamic Semantics
Run-to-completion model:
seriali&ed event handlin(
eliminates internal concurrenc$
minimal context switchin( overhead
ActiveObject:
Active1 Active1 Active2 Active2
1he ?%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'6priority
event
hi
hi
lo
Next slides are
asic State !achine Concepts
Statecharts an" Ob#ects
A"vance" !o"e$ing Concepts
Case St%"y


State 0ntry an" 0&it Actions
A "ynamic assertion mechanism
LampOn
entry/lamp.on();
exit/lamp.off();
e1
e2
Resulting action sequence:
printf(exiting);
printf(to off);
lamp.off();
Or"er o) Actions/ Simp$e Case
0&it actions pre)i& transition actions
0ntry action post)i& transition actions
printf(exiting);
lamp.off();
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);
5nterna$ 1ransitions
Se$)6transitions that bypass entry an" e&it
actions
LampOff
entry/lamp.off();
exit/printf(exiting);
off/null;
Internal transition
triggered by
an off event
Error
entry/printf(error!)
State ,Do- Activities
;or9s a conc%rrent threa" that e&ec%tes %nti$/
the action comp$etes or
the state is e&ite" thro%gh an o%tgoing transition
do/while (true) alarm.ring();
do activity
.%ar"s
Con"itiona$ e&ec%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
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
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
Dynamic
choicepoint
:ierarchica$ State !achines
.ra"%ate" attac9 on comp$e&ity
states "ecompose" into state machines
LampFlashing
flash/
1sec/
1sec/
FlashOff
entry/lamp.off()
FlashOn
entry/lamp.on()
off/
LampOff
entry/lamp.off()
LampOn
entry/lamp.on()
on/
on/
on/
St%b Notation
Notationa$ shortc%t/ no semantic signi)icance
LampFlashing
flash/
on/
FlashOn
FlashOff
off/
LampOff
entry/lamp.off()
LampOn
entry/lamp.on()
on/
on/
LampFlashing
1sec/
1sec/
FlashOff
entry/lamp.off()
FlashOn
entry/lamp.on()
off/
LampOff
entry/lamp.off()
LampOn
entry/lamp.on()
on/
.ro%p 1ransitions
:igher6$eve$ transitions
flash/
on/
Default transition to
the initial pseudostate
Group transition
Comp$etion 1ransitions
1riggere" by a comp$etion event
generate" a%tomatica$$y 'hen an imme"iate$y neste" state
machine terminates
Committing
Phase1
Phase2
CommitDone
completion
transition (no trigger)
LampFlashing
off/
FlashOff
FlashOn
1riggering ?%$es
1'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/
De)erre" 0vents
0vents can be retaine" i) they "o not trigger a
transition

off/
LampOn
entry/lamp.on()
on/
LampOff
entry/lamp.off()
off/defer
Deferred event
Or"er o) Actions/ Comp$e& Case
Same approach as )or the simp$e case
S1
exit/exS1
S11
exit/exS11
S2
entry/enS2
S21
entry/enS21
initS2
E/actE
Actions execution sequence:
exS11 exS1 actE enS2 initS2 enS21
suspend/
:istory
?et%rn to a previo%s$y visite" hierarchica$ state
"eep an" sha$$o' history options
Diagnosing
Diagnostic1
Step11
Step12
Diagnostic2
Step21
Step22
resume/
H*
Orthogona$ity
!%$tip$e sim%$taneo%s perspectives on the same entity
Child
Adult
Retiree
age
Poor
Rich
financialStatus
Orthogona$ ?egions
Combine m%$tip$e sim%$taneo%s "escriptions
Child
Adult
Retiree
age
Poor
Rich
financialStatus
Poor
Rich
financialStatus
Child
Adult
Retiree
age
Outlaw
LawAbiding Poor
Rich
financialStatus
legalStatus
Orthogona$ ?egions 6 Semantics
A$$ m%t%a$$y orthogona$ regions "etect the same events
an" respon" to them sim%$taneo%s$y
%s%a$$y re"%ces to inter$eaving o) some 9in"
robBank/ robBank/
Catch22
sanityStatus flightStatus
5nteractions et'een ?egions
1ypica$$y thro%gh share" variab$es or a'areness o)
other regions state changes
(flying)/
Crazy
entry/sane := false;
Sane
entry/sane := true;
request
Grounding/
Flying
entry/flying := true;
Grounded
entry/flying := false;
(sane)/
(~sane)/
sane : Boolean
flying : Boolean
1ransition ;or9s an" @oins
;or transitions into8o%t o) orthogona$ regions/
Staff
Member
employee
Child Adult Retiree
age
Manager
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
Ne&t s$i"es are
asic State !achine Concepts
Statecharts an" Ob#ects
A"vance" !o"e$ing Concepts
Case St%"y



line card 1


line card N End 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
AB
receiver
End user
End user
AB
sender
AB
receiver
AB protocol
packetizer unpacker Receiver Sender
A$ternating it Protoco$ ,1-
A simp$e one6'ay point6to6point pac9et protoco$
data(1)
ackA
pktA
data(1)
ack
ack
data(2)
ackB
pktB
data(2)
ack
ack
etc.
AB protocol
A$ternating it Protoco$ ,2-
State machine speci)ication
ackB/^ack
data/^pktA
ackA/^ack data/^pktB
timeout/^pktB
timeout/^pktA
Sender SM
AcceptPktA
WaitAckA
AcceptPktB
WaitAckB
pktA/^data
ack/^ackA
pktB/^data
ack/^ackB
timeout/^ackB
timeout/^ackA
RcvdPktA
WaitPktB
RcvdPktB
WaitPktA
Receiver SM
A""itiona$ Consi"erations
S%pport ,contro$- in)rastr%ct%re






SWITCH
AB
receiver
AB
sender
operator
interface
DB
interface
System
operator
DBase
AB lines
manager
Contro$
The set of (additional) mechanisms and actions
required to ring a system into the desired
operational state and to maintain it in that state in
the 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 up(rade

?etro)itting Contro$ ehavior
AcceptPktA
WaitAckA
AcceptPktB
WaitAckB
Failed
JustCeated
!ad"ae
Audit
#ettin$%ata
&ead'(o#o
Anal'sin$
Failue
1he 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
0&p$oiting 5nheritance
Abstract contro$ c$asses can capt%re the
common contro$ behavior
AbstractController
Sender Receiver . . .
Failed
JustCeated
!ad"ae
Audit
#ettin$%ata
&ead'(o#o
Anal'sin$
Failue
Opeational
0&p$oiting :ierarchica$ States
AbstractController
Sender
Activity Diagrams

Activity Diagram App$ications
5nten"e" )or app$ications that nee" contro$ )$o' or
ob#ect8"ata )$o' mo"e$s
... rather than event6"riven mo"e$s $i9e state
machines.
;or e&amp$e/ b%siness process mo"e$ing an"
'or9)$o'.
1he "i))erence in the three mo"e$s is ho' step in a
process is initiate"* especia$$y 'ith respect to ho' the
step gets its inp%ts.
Contro$ ;$o'
0ach 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%$$-.
0mphasis is on or"er in 'hich steps are ta9en.
Not UML
Notation!
Chart Course
Cancel Trip
Analyze Weather Info
Weather Info
Start
Ob#ect8Data ;$o'
0ach 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-.
0mphasis is on ob#ects )$o'ing bet'een steps.
Design Product
Procure
Materials
Acquire Capital
Subassembly 1
Build
Subassembly 1
Subassembly 2
Build
Subassembly 2
Final
Assembly
Not UML
Notation
State !achine
0ach step is ta9en 'hen events are "etecte" by the
machine
%sing inp%ts given by the event.
0mphasis is on reacting to environment.
Ready To Start
Coin Deposited
Ready For Order
Selection Made
Dispense
Product
Return
Change
Cancel Button
Pressed
Not UML
Notation
C%rrent$y activity graphs are mo"e$e" as a 9in"
o) state machine.
!o"e$er "oesnAt 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
@%st $i9e their state machine co%nterparts ,simp$e
state an" s%bmachine state- e&cept that ...
... transitions coming o%t o) them are ta9en 'hen the
step is )inishe"* rather than being triggere" by a
e&terna$ event* ...
... an" they s%pport "ynamic conc%rrency.

Action
Action (State

Subactivity
Subactivit$ (State

3in"s o) Steps in Activity Diagrams
Action ,State-
An action is %se" )or anything that "oes not "irect$y
start another activity graph* $i9e invo9ing an operation
on 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
S%bactivity ,State-
A s%bactivity ,state- starts another activity graph
'itho%t %sing an operation.
Use" )or )%nctiona$ "ecomposition* non6po$ymorphic
app$ications* $i9e many 'or9)$o' systems.
1he invo9e" activity graph can be %se" by many
s%bactivity states.
Subactivity
0&amp$e
POEmployee.sortMail Deliver Mail
POEmployee
sortMail()
Check Out
Truck
Put Mail
In Boxes
Deliver Mail
POEmployee
sortMail()
Activity .raph as !etho"
App$ication is comp$ete$y OO 'hen a$$ action states invo9e
operations
A$$ activity graphs are metho"s )or operations.
POEmployee.sortMail POEmployee.deliverMail
deliverMail()
realize
Check Out
Truck
Put Mail
In Boxes
PO Employee Deliver Mail Method
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 e&pression eva$%ate" at
r%ntime. 0&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 e&pression
or ho' arg%ments are accesse" by actions. Attach a note
as 'or9aro%n" )or e&pression. 5ss%e )or U!L 2.0.
Action/Subactivity
*
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 ne&t step ,state-.
P$aces constraints on inp%t an" o%tp%t parameters o)
steps be)ore an" a)ter it.
Class
[State]
Ob#ect ;$o' ,State-
1a9e Or"er m%st have an o%tp%t parameter giving
an or"er* or one o) its s%btypes.
;i$$ Or"er m%st have an inp%t parameter ta9ing an
or"er* or one o) its s%pertypes.
Dashe" $ines %se" 'ith ob#ect )$o' have the same
semantics as any other state transition.
Order
[Taken]
Take Order Fill Order
Coor"inating Steps
-nitial state
)inal state
)or. and #oin
-nherited from state machines
Decision point an" merge , - are inherite"
)rom state machines.
;or mo"e$ing conventiona$ )$o' chart "ecisions.
Coor"inating Steps
Calculate
Cost
Charge
Account
Get
Authorization
[cost < $50]
[cost >= $50]
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
Inspect
Install
Foundation
Build
Frame
Install
Electricity
in Foundation
Put
On
Roof
Install
Electricity
In Frame
Install
Electricity
Outside
Install
Walls
* *
;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-.
Build
Frame
Install
Foundation
Install
Electricity
in Foundation
Put
On
Roof
Install
Electricity
In Frame
Install
Electricity
Outside
Install
Walls
Inspect
Activity diagram
notation
Convenience ;eat%res ,Synch State-
Ob#ect )$o' states can be synch states
Obj
[S2]
A11 A12 A13
A21 A22 A23
Convenience ;eat%res ,Synch State-
Convenience ;eat%res
;or9 transitions can have g%ar"s.
Register
Bug
Evaluate
Impact
Fix
Bug
Revise
Plan
Release
Fix
Test
Fix
[ priority = 1]
Register
Bug
Evaluate
Impact
Fix
Bug
Revise
Plan
Release
Fix
Test
Fix
[ priority = 1]
[else]
-nstead of doin( this*
Convenience ;eat%res
Partitions are a gro%ping mechanism.
S'im$anes are the notation )or partitions.
1hey "o not provi"e "omain6speci)ic semantics.
1oo$s can generate s'im$ane presentation )rom "omain6
speci)ic in)ormation 'itho%t partitions.

Register
Bug
Evaluate
Impact
Fix
Bug
Revise
Plan
Release
Fix
Test
Fix
[ priority = 1]
Management
Support
Engineering
Convenience ;eat%res
Si(nal send icon
Signal
Coffee
Pot
Wake Up
Get Cups
Turn on Coffee Pot
Coffee Done
Drink Coffee
Signal
translates to a transition with a
send action/
Si(nal receipt icon
translates to a wait state (a
state with no action and a si(nal
tri((er event/


2hen to Use Activity Diagrams
Use activity "iagrams 'hen the behavior yo%
are mo"e$ing ...
"oes not "epen" m%ch on e&terna$ 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 more
concerne" 'ith 'hich activities happen* rather than
'hich ob#ects are responsib$e )or them ,e&cept
partitions possib$y-.

Activity Diagram !o"e$ing 1ips
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'.
Co% can mi& state machine an" contro$8ob#ect
)$o' constr%cts on the same "iagram ,tho%gh
yo% probab$y "o not 'ant to-.
Activity Diagram !o"e$ing 1ips
Request
Return
Get Return
Number
Ship Item
Item
[returned]
Receive
Item
Restock
Item
Credit
Account
Item
[available]
Customer Telesales Warehouse Accounting
From UML
User Guide:
A
c
t
i
v
i
t
y

!
o
"
e
$
i
n
g

1
i
p
s

Request
Return
Get Return
Number
Ship Item
Item
[returned]
Receive
Item
Restock
Item
Credit
Account
Item
[available]
Customer Telesales Warehouse Accounting
Activity Diagram !o"e$ing 1ips
Activity "iagrams inherit )rom state machines the
re(%irement )or 'e$$6str%ct%re" nesting o) composite states.

1his 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 that
is 'e$$6neste".

1his ins%res that "iagram is e&ec%tab$e %n"er state machine
semantics.
Activity Diagram !o"e$ing 1ips
Well-nested:
Not well-nested:
Activity Diagram !o"e$ing 1ips
Apply structured coding principles. (Be careful with gotos!)
Activity Diagram !o"e$ing 1ips
Can be translated to well-nested
diagram on earlier slide:
0&amp$e / Login o) an on$ine ban9ing
system
Activity
diagram
withdraw
money
(ATM)
2rap 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.D has ne' )eat%res )or b%siness mo"e$ing that
increase po'er an" convenience. Chec9 it o%t an" give
)ee"bac9E