UML Statecharts

UML State Diagrams
A. Fantechi
1/4/2010
Macchina a Stati Finiti
(Automa a stati finiti, Finite State Machine, FSM)
• Descrizione grafica del comportamento di una FSM
on
Lamp On
on
off
off
Lamp Off
Macchina a Stati Finiti
(Automa a stati finiti, Finite State Machine, FSM)
• Descrizione formale del comportamento di una FSM:
• Una FSM M è una quadrupla (S, s0, E, R) dove:
– S è un insieme finito di stati
– s0 ! S è lo stato iniziale
– E è un insieme di eventi (trigger)
– R " S x E xS è la relazione di transizione.
(s1, e, s2) ! R si scrive anche s1
e
s2
Nondeterminismo
• Spesso si usa una funzione di
transizione invece di una
relazione di transizione:
– R: S x E # S
In questo modo il prossimo stato è
sempre determinato
univocamente dall’evento di input.
Caso di nondeterminismo -->
Uscite, azioni
• Uscite generate dall’automa:
on
on
Lamp On
print(
”on”)
print(”on”)
Lamp
On
on
on/print(”on”)
off
Lamp
Off
off
off
Macchina di Mealy
Lamp
Off
off
Macchina di Moore
Descrizione formale macchine Mealy e Moore
• Una Macchina di Mealy è una sestupla (S, s0, E, R, O, o) dove:
– S è un insieme finito di stati
– s0 ! S è lo stato iniziale
– E è un insieme di eventi (trigger)
– R : S x E # S è la funzione di transizione.
– O è un insieme di possibili uscite
– o : S x E # O è la funzione di uscita
• Una Macchina di Moore è una sestupla (S, s0, E, R, O, o) dove:
– S è un insieme finito di stati
– s0 ! S è lo stato iniziale
– E è un insieme di eventi (trigger)
– R : S x E # S è la funzione di transizione.
– O è un insieme di possibili uscite
– o : S # O è la funzione di uscita
(determinismo)
Extended Finite State Machines
(EFSM)
• Estensione con variabili (“extended state”)
on
ctr
ctr :: Integer
Integer
Lamp On
on/ctr := ctr + 1
off
off
Lamp Off
EFSM
• Una EFSM (di Mealy) è definita da:
– Un insieme di segnali di input (input alphabet)
– Un insieme di segnali di output (output alphabet)
– Un insieme di stati
– Un insieme di transizioni
• segnale di trigger
• guardia
• azione
– Un insieme di variabili (extended state variables)
– Un’indicazione di stato iniziale (stato iniziale + valore iniziale
delle variabili)
– Un insieme di stati finali (vuoto nel caso di macchina non
terminante)
Harel Statecharts
• Create da David Harel (I-Logix) alla fine degli anni ‘80, come
ulteriore estensione delle EFSM
• Formano la base del modello comportamentale di UML
• Supportano
– Stati annidati (gerarchie di stati)
– Azioni su
• Transizioni
• Entry (ingresso in uno stato)
• Exit (uscita da uno stato)
– Attività eseguite all’interno di uno stato (Do)
– Guardie
– History
– Eventi di Broadcast
– Regioni Ortogonali (AND-States)
9
Basic UML Statechart Diagram
““top”
top”
top” state
Initial
pseudostate
State
top
Trigger
Ready
Transition
stop /ctr := 0
Final
state
Done
stop
Action
Che tipo di comportamento?
• In generale, le EFSM sono adatte per descrivere
un comportamento dicreto, event-driven
– inappropriate per modellare comportamento continuo
– in UML non ci sono strumenti per modellare un
comportamento continuo
threshold
time
Comportamento Event-Driven
• Evento = un tipo di occorrenza di qualcosa di
osservabile
– interazioni:
• Invocazione sincrona di un metodo di un oggetto (call event)
• Ricezione asincorna di un segnale (signal event)
– Occorrenza di istanti di tempo (time event)
• Scadenza di un intervallo
• Tempo di clock o di calendario
– Aggiornamento del vlore di una variabile (change event)
• Istanza di un Evento (Event Instance) = un’istanza
di un tipo di evento che accade in un certo istante
di tempo e che non ha durata
Comportamento Event-Driven - UML
• In linea di principio, si può parlare di comportamento eventdriven per un qualsiasi tipo di sistema
• In UML, il comportamento event-driven è quello manifestato
dagli oggetti. Quindi possiamo associare agli oggetti di una
classe un comportamento event-driven specificato
attraverso uno state diagram.
• La semantica degli state diagram UML è data principalmente
in relazione ad oggetti attivi
Comportamento di un oggetto Passivo Modello Generale
Trattamento
Trattamento dello
dello specifico
specifico
metodo
richiesto
metodo richiesto
Initialize
Initialize
Object
Object
Wait
Waitfor
for
Request
Request
void:offHook ();
{busy = true;
obj.reqDialtone();
…
};
Handle
Handle
Request
Request
Terminate
Terminate
Object
Object
Oggetti Passivi e Macchine a Stati
• mapping:
on
Initialize
Object
Lamp
On
Wait for
Event
on/print(”on”)
off
Handle
Event
Lamp
Off
Terminate
Object
off
stop
Oggetti e flussi di controllo (threads)
• Oggetti Passivi: flusso di controllo esterno
• Oggetti Attivi: proprio flusso di controllo
Initialize
Initialize
Object
Object
Initialize
Initialize
Object
Object
Wait
Waitfor
for
Request
Request
Wait
Waitfor
for
Request
Request
Handle
Handle
Request
Request
Handle
Handle
Request
Request
Terminate
Terminate
Object
Object
Terminate
Terminate
Object
Object
Flussi concorrenti
Initialize
Initialize
Object
Object
Wait
Waitfor
for
Request
Request
Handle
Handle
Request
Request
Terminate
Terminate
Object
Object
• Un oggetto passivo può essere attraversato da flussi concorrenti:
--> problema di sincronizzazione
• Un oggetto attivo ha un proprio, unico, flusso: la concorrenza si
ottiene con due oggetti attivi, istanze distinte della stessa classe
Oggetti Attivi e Macchine a Stati
• Oggetti Attivi con il proprio flusso di controllo
anActiveObject
#currentEvent : Eventpoll/defer
created
start
+ start ( )
+ poll ( )
+ stop ( )
start/^master.ready()
ready
ready
stop/
poll/^master.ack()
Le variabili di stato esteso sono gli attributi dell’oggetto.
Semantica degli Oggetti Attivi
ActiveObject:
Coda di
eventi
Run-to-completion model
Run-to-completion model
• Il run-to-completion model step definisce come avviene una
transzione tra due configurazioni della macchina a stati.
• Configurazione = stato corrente + valore delle variabili di
stato esteso + situazione della coda in ingresso
• Un evento in coda (received) può essere prelevato
(dispatched) dalla coda e trattato solo quando l’elaborazione
dell’evento precedente è terminata (consumed).
• Durante uno step di run-to-completion può essere eseguita
una sequenza di varie attività, che possono includere la
modifica di un attributo locale, l’invio di un segnale,
l’invocazione di un metodo di un altro oggetto, la rimozione di
un evento dalla coda di ingresso
Stati UML
Initializing Valve
ValveOk: Boolean = FALSE
ValveAperture: int = 0
cmdSize: int
entry / ValveOK = TestValve( )
do / OpenTo(cmdSize: int)
exit / printMessage(ValveAperature)
Sintassi completa
guard
event parameters
action list
event name
A
entry / g(x), h(y)
exit / m(a), n(b)
do / act(a,y,z)
defer / e1, e2
e3 / p(x,y), q(z)
T1(int r)[r < 0] / f(r)
B
entry actions
exit actions
activities
state name
deferred events
internal transition
state
22
Eventi
• Un evento può essere:
– Una condizione che diventa vera (guardia)
– Ricezione di un esplicito segnale da un altro oggetto
– Ricezione di una chiamata a un metodo da un altro
oggetto
– Timeout (passage of a specified interval)
• Eventi possono causare transizioni di stato
(etichette sulle) Transizioni
event-name (parameter list) [guard] /
action expression
• event-name nome dell’evento di trigger per la transizione
• parameter list
parametri con tipo (opzionale)
• guard espressione Booleana sui parametri e sugli attributi
dell’oggetto (variabili)
• action-expression lista di operazioni da eseguire quando la
transizione viene selezionata: la lista è eseguita
atomicamente
Esempi di etichette sulle transizioni
•
JustDoIt
•
JustDoIt(x)
•
JustDoIt(x: int)
•
JustDoIt(x) [x>0]
•
JustDoIt [y<10] / print(y)
•
JustDoIt(x,y) [x>y+10] / print (x+y);
target->genSignal(Nike.MakeMoney(MuchoDollaro))
Tipi di Eventi
• UML definisce 4 tipi di eventi
– Signal Event
• Ricezione di un segnale Asinchrono
• e.g. evFlameOn
– Call Event
• Ricezione di un’invocazione di un metodo
• e.g. op(a,b,c)
– Change Event
• Aggiornamento del valore di una variabile (condivisa)
– Time Event
• Scadenza di un tempo Relativo (intervallo)
• Raggiungimento di un tempo Assolute
• e.g. tm(PulseWidthTime)
State Entry and Exit Actions
LampOn
entry/lamp.on();
e2
exit/lamp.off();
e1
Ordine delle Azioni: un caso semplice
• Exit actions precedono le transizioni
• Entry action seguono le transizioni
LampOn
entry/lamp.on();
off/printf(“to off”);
exit/printf
exit/printf((“exiting”
exiting”);
Sequenza di azioni risultante
printf
(“exiting”);
printf(“exiting”);
printf
(“to off
”);
printf(“to
off”);
lamp.off();
LampOff
entry/lamp.off();
exit/printf
exit/printf((“exiting”
exiting”);
off/printf(“needless”);
printf
(“exiting”);
printf(“exiting”);
printf
(“needless”);
printf(“needless”);
lamp.off();
Transizioni Interne
• Self-transitions
• Non provocano l’esecuzione di entry e exit actions
transizione interna
triggered da
un ““off”
off” event
LampOff
entry/lamp.off();
exit/printf
exit/printf((“exiting”
exiting”);
off/null;
State (“Do”) Activities
• thread concorrente che esegue fino a che:
– l’attività è completata
oppure
– si esce dallo stato con una transizione uscente
““do”
do” activity
Error
entry/printf
entry/printf((“error!”
error!”)
do/while (true) alarm.ring();
Guardie
• Esecuzione Condizionale di transizioni
– Le guardie (predicati Booleani) non devono avere side-effect
bid [value < 100] /reject
Selling
bid [value >= 200] /sell
Happy
bid [(value >= 100) & (value < 200)] /sell
Unhappy
Static Conditional Branching
• Abbreviazione grafica per evidenziare una signola
transizione uscente
Selling
bid
[value >= 200] /sell
[value < 100] /reject
[(value >= 100) & (value < 200)] /sell
Unhappy
Happy
Dynamic Conditional Branching
• Choice pseudostate: le guardie vengono valutate
solo quando viene raggiunto lo pseudostato.
Happy
Selling
bid /gain := calculatePotentialGain(value)
[gain >= 200] /sell
[gain < 100] /reject
[(gain >= 100) & (gain < 200)] /sell
Dynamic
Dynamic
choicepoint
choicepoint
Unhappy
Macchine a stati gerarchiche
• stati decomposti ricorsivamente in macchine a stati
LampOff
entry/lamp.off()
flash/
LampFlashing
FlashOn
entry/lamp.on()
off/
on/
LampOn
entry/lamp.on()
1sec/
on/
on/
1sec/
FlashOff
entry/lamp.off()
OR States
• Migliorano la scalabilità
• Migliorano la comprensibilità
• Permettono la decomposizione gerarchica di un
problema (divide-and conquer)
• Possibilità:
– Stati annidati sullo stesso diagramma
– Stati annidati su diagrammi separati
• aka “submachines”
35
Sintassi
ev_2
or-states
state
nested
state
OR States
Statechart gerarchica
entry/ Print(ErrCode)
Group Transitions
• Transizioni a più alto livello nella gerarchia di stati
Default transition to
the initial pseudostate
LampOff
entry/lamp.off()
LampFlashing
flash/
FlashOn
entry/lamp.on()
off/
1sec/
on/
FlashOff
on/
LampOn
1sec/
entry/lamp.off()
entry/lamp.on()
Group transition
Completion Transitions
• Triggered da un evento di completion
– generato automaticamente quando uno macchina
immediatamente annidata termina
Committing
completion
transition (no trigger)
Phase1
Phase1
CommitDone
Phase2
Phase2
Regole di Triggering
• Due o più transizioni possono avere lo stesso evento trigger
– La transizione più interna ha la precedenza
– Un evento in coda è consumato sia che attivi una transizione sia
che non attivi alcuna transizione.
LampFlashing
FlashOn
on/
on/
off/
FlashOff
Ordine delle azioni annidate
• Da fuori a dentro le azioni entry
• Da dentro a fuori le azioni exit
U
entry: f()
exit: g(a,b)
U1 entry: x(c)
exit: y()
first f() then x(c)
A
first y() then g(a,b)
42
Deferred Events
•
Gli eventi in coda che non possono
attivare una transizione vengono
scartati, fino a che un evento in
grado di attivare una transizione
non venga trovato nella coda.
•
Deferred events
– Se però un evento è in una
“deferred” list, non viene scartato e
rimane in coda (finchè rimane nella
deferred list)
– Se l’oggetto transisce in uno stato
dove l’evento non è più presente in
una deferred list, tale evento viene
scartato.
LampOff
Deferred event
entry/lamp.off()
off/defer
off/
on/
LampOn
entry/lamp.on()
Ordine delle Azioni: Caso Complesso
S1
exit/exS1
S2
entry/enS2
initS2
S11
exit/exS11
E/actE
S21
entry/enS21
sequenza di esecuzione delle Azioni,
in caso di triggering della transizione
exS11 ! exS1 ! actE ! enS2 ! initS2 ! enS21
Ortogonalità
• Viste multiple simultanee sulla stessa entità
age
financialStatus
Child
Poor
Adult
Retiree
Person
Rich
AND-States
• Gli stati possono essere decomposti in
– OR-States
• Uno stato (super-stato) può essere decomposto in un numero qialsiasi
di OR-States
• Quando l’oggetto si trova in un super-stato, deve trovarsi in UNO dei
suoi OR-substates.
oppure
– AND-State
• Uno stato (super-stato) può essere decomposto in un numero qialsiasi
di AND-States (regioni ortogonali)
• Quando l’oggetto si trova in un super-stato, deve trovarsi in TUTTI i
suoi AND-substates attivi.
• Regioni separate da linee tratteggiate
Regioni Ortogonali
• Combinazione di descrizioni multiple simultanee
age
financialStatus
Child
Poor
Adult
Retiree
age
financialStatus
Rich
Child
Poor
Adult
Retiree
Rich
AND-States
AND-States
transition
state
initial
pseudostate
and-states
conditional
pseudostate
Regioni Ortogonali - Semantica
• Tutte le regioni ortogonali reagiscono allo stesso
evento, (in principo) simultaneamente.
legalStatus
LawAbiding
robBank/
robBank/
Outlaw
financialStatus
Poor
robBank/
robBank/
Rich
AND-States & Concorrenza
• Gli AND-states non sono necessariamente concorrenti
• Semantica degli AND-states tipicamente a interleaving
• UML usa la concorrenza tra oggetti attivi come
principale modo di modellare la concorrenza
• Gli AND-states possono essere implementati come
threads concorrenti, ma questa non è l’unica strategia
di implementazione corretta.
Uso concettualmente errato dell’ortogonalità
• Uso di regioni per modellare oggetti attivi independenti
Person1
Person2
Person1
• Soluzione:
Person2
Child
Child
Adult
Adult
Retiree
Retiree
--> due istanze dello stesso oggetto attivo !!!
Interazioni tra Regioni
• Tipicamente, attraverso variabli condivise o riferimenti a
cambio di stato delle altre regioni.
sane
sane :: Boolean
Boolean
flying
flying :: Boolean
Boolean
Catch22
Catch22
sanityStatus
flightStatus
Crazy
entry/sane
entry/sane :=
:= false;
false;
Flying
entry/flying
entry/flying :=
:= true;
true;
(flying)/
request
Grounding/
(sane)/
(~sane)/
Sane
entry/sane
entry/sane :=
:= true;
true;
Grounded
entry/flying
entry/flying :=
:= false;
false;
AND-State Communication
• Gli AND-states possono communicare via:
– Broadcast events
• Ricevuti da tutti gli AND-states attivi
– Propagated events
• Una transizione in un AND-state può inviare un evento sentito da un
altro AND-state
– Guardie
• [IS_IN( state )] usa il substate di un AND-state in una guardia
– Attributi
• Siccome gli AND-states fano parte dello stesso oggetto, vedono tutti
gli attributi dell’oggetto (variabili condivise)
Propagazione e Broadcast
/
55
Fork e Join
• Transizioni verso/da regions ortogonali:
age
Child
Child
Staff
Staff
Member
Member
Adult
Adult
Retiree
Retiree
Manager
Manager
employee
Transizioni Complesse
S
fork
join
S1
e2
S1_2
S1_1
e5
B
A
e1
e5
S2_1
e3
S2_2
S2
e4
C
pseudostates
initial
pseudostate
conditional
pseudostate
terminal
pseudostate
history
pseudostate
Pseudostates
Symbol
Symbol Name
Symbol
C
or
Branch Pseudostate (type of
junction pseudostate)
T
or
Terminal or Final Pseudostate
*
or
n
Symbol Name
H
(Shallow) History Pseudostate
H*
(Deep) History Pseudostate
Synch Pseudostate
Initial or Default Pseudostate
Fork Pseudostate
Junction Pseudostate
Join Pseudostate
Merge Junction Pseudostate
(type of junction pseudostate)
[g]
Choice Point Pseudostate
Stub Pseudostate
[g]
label
History
• Ritorno a uno stato gerarchico già visitato
– deep /shallow history
Diagnosing
suspend/
resume/
H*
H*
Diagnostic1
Diagnostic1
Diagnostic2
Diagnostic2
Step11
Step11
Step21
Step21
Step12
Step12
Step22
Step22
Deep History
Shallow History
Synch Pseudostate
• Permette di far scattare una transizione solo quando
un insieme di transizioni è avvenuto
• “Memorizza” che una o più specifiche transizioni sono
avvenute,
• Simile al posto (piazza, place) di una Rete di Petri
• Permette di sincronizzare più AND-States
“Synch” Pseudostate
Data Processing
Waiting for
Data
Processing
Datum
dataSignal
Logging
Data
Synch Pseudostate
with unbounded
multiplicity
synch state
*
User Monitoring
Applying
Alarm
Filters
/active alarm ct = 0
Waiting to
Process
Alarms
[else]
/active alarm ct = 0
Alarm
Processing
done
tm(displayTime)
C
Idle
alarmRaised
[active alarm ct > 0]/
genSignal(alarmRaised)
Displaying
Alarms
Waiting to
accept
accept
1
synch state
“Stub” Notation
• Abbreviazione notazionale: nessuna aggiunta
semantica
LampOff
entry/lamp.off()
flash/
LampFlashing
FlashOn
off/
on/
LampOn
on/
on/
FlashOff
entry/lamp.on()
Submachines: Reference
stub state
reference
toOn(mode: tMode)
defaultMode = mode;
Self Testing
include / BITSubmachine
device Test
On
done(defaultMode)
Operating
include / OpsSubmachine
RAM Test
doTest
Normal
Failsafe
Abort
[else]
doRAMtest
Off
[recoverOK]
doDeviceTest
toOff
Unrecoverable
Error
submachine
indicator
errorFound
C
errorHandled
Submachines: Referenced
submachine
BITSubmachine
OpsSubmachine
entry / isError = false;
doDeviceTest
done
Testing
ROM
[m == normal]
C
RAM
Test
Testing
Components
Normal
Mode
(m: tMode)
Testing
RAM
[else]
Demo
Mode
errorFound/
isError = true;
[m == failsafe]
device Test
stub state
Failsafe
Mode
Abort
Logging
Test
Results
Normal
doRAMtest
[else]
C
[isError == false]
done
Failsafe
toOff
errorFound
Normal
subEnd
Uso degli State Diagrams
• Specifica del comportamento di un sistema
(necessita di uno strumento di editing)
• Simulazione
(necessita di uno strumento di simulazione)
• Verifica (Model checking)
(necessita di uno strumento di verifica)
• Generazione automatica del codice
(necessita di un generatore di codice)
doTest
Credits
Bruce Powel Douglass, Real-Time UML, Slides, Ilogix
Gunnar Övergaard, Bran Selic, Conrad Bock, Behavioral
Modeling, Object Modeling with OMG UML Tutorial Series,
UML Revision Task Force, Nov. 2000