Macchina a Stati Finiti (Automa a stati finiti, Finite State Machine, FSM) Descrizione grafica del comportamento di una FSM on UML State Diagrams Lamp On A. Fantechi 1/4/2010 off on Lamp Off 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, s 0, E, R) dove: S è un insieme finito di stati s 0 S è lo stato iniziale E è un insieme di eventi (trigger) R S x E xs è la relazione di transizione. 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 --> (s 1, e, s 2 ) R si scrive anche s 1 e s 2 1
Uscite, azioni Uscite generate dall automa: off Lamp On Lamp Off on print( print( on ) off Macchina di Mealy Lamp On print( on ) off Lamp Off on on off Macchina di Moore Descrizione formale macchine Mealy e Moore Una Macchina di Mealy è una sestupla (S, s 0, E, R, O, o) dove: S è un insieme finito di stati s 0 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, s 0, E, R, O, o) dove: S è un insieme finito di stati s 0 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 ) ctr : Integer off Lamp On Lamp Off on ctr := ctr + 1 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) 2
Harel Statecharts Basic UML Statechart Diagram 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) Initial pseudostate Transition Final state top state top Ready Done stop /ctr := 0 stop State Trigger Action 9 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 3
Comportamento Event-Driven - UML Comportamento di un oggetto Passivo - Modello Generale 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 Trattamento dello specifico metodo richiesto void:offhook (); {busy = true; obj.reqdialtone(); }; Initialize Wait Wait for for Handle Terminate Oggetti Passivi e Macchine a Stati Oggetti e flussi di controllo (threads) mapping: Initialize Wait for Event Handle Event Terminate on Lamp On print( on ) off off Lamp Off stop Oggetti Passivi: flusso di controllo esterno Oggetti Attivi: proprio flusso di controllo Initialize Initialize Wait Wait for for Handle Handle Terminate Terminate Initialize Initialize Wait Wait for for Handle Handle Terminate Terminate 4
Flussi concorrenti Initialize Initialize Wait Wait for for Handle Handle Terminate Terminate Oggetti Attivi e Macchine a Stati Oggetti Attivi con il proprio flusso di controllo anactive #currentevent : Event poll/defer created start + start ( ) + poll ( ) + stop ( ) start/^master.ready() ready ready stop/ 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 poll/^master.ack() Le variabili di stato esteso sono gli attributi dell oggetto. Semantica degli Oggetti Attivi Run-to-completion model Coda di eventi Run-to-completion model Active: 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 5
Stati UML Sintassi completa Initializing Valve ValveOk: Boolean = FALSE ValveAperture: int = 0 cmdsize: int entry / ValveOK = TestValve( ) do / OpenTo(cmdSize: int) exit / printmessage(valveaperature) A event parameters event name 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) entry actions exit actions activities deferred events internal transition state name state guard action list B 22 Un evento può essere: Eventi 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 6
Esempi di etichette sulle transizioni Tipi di Eventi 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)) 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 Ordine delle Azioni: un caso semplice Exit actions precedono le transizioni Entry action seguono le transizioni LampOn entry/lamp.on(); exit/lamp.off(); e1 e2 LampOn entry/lamp.on(); exit/printf printf( exiting ); off/printf printf( to to off ); Sequenza di azioni risultante printf( exiting ); printf( to to off ); lamp.off(); LampOff entry/lamp.off(); exit/printf printf( exiting ); off/printf printf( needless ); printf( exiting ); printf( needless ); needless ); lamp.off(); 7
Transizioni Interne State ( Do ) Activities Self-transitions Non provocano l esecuzione di entry e exit actions transizione interna triggered da un off event LampOff entry/lamp.off(); exit/printf printf( exiting ); off/null; thread concorrente che esegue fino a che: l attività è completata oppure si esce dallo stato con una transizione uscente Error entry/printf printf( error! error! ) do/while (true) alarm.ring(); do activity Guardie Esecuzione Condizionale di transizioni Le guardie (predicati Booleani) non devono avere side-effect bid [value < 100] /reject Selling bid [value >= 200] /sell Happy Static Conditional Branching Abbreviazione grafica per evidenziare una signola transizione uscente Selling Happy bid bid [(value >= 100) & (value < 200)] /sell [value < 100] /reject [value >= 200] /sell [(value >= 100) & (value < 200)] /sell Unhappy Unhappy 8
Dynamic Conditional Branching Choice pseudostate: le guardie vengono valutate solo quando viene raggiunto lo pseudostato. Macchine a stati gerarchiche stati decomposti ricorsivamente in macchine a stati [gain < 100] /reject Dynamic choicepoint Selling Unhappy bid /gain := calculatepotentialgain(value) [gain >= 200] /sell [(gain >= 100) & (gain < 200)] /sell Happy LampOff entry/lamp.off() off/ LampOn entry/lamp.on() flash/ LampFlashing 1sec/ FlashOn entry/lamp.on() 1sec/ FlashOff entry/lamp.off() OR States Sintassi state 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 or-states ev_2 nested state 35 9
OR States Statechart gerarchica entry/ Print(ErrCode) Group Transitions Transizioni a più alto livello nella gerarchia di stati Default transition to the initial pseudostate Completion Transitions Triggered da un evento di completion generato automaticamente quando uno macchina immediatamente annidata termina LampOff entry/lamp.off() off/ flash/ LampFlashing FlashOn entry/lamp.on() Committing Phase1 completion transition (no trigger) LampOn entry/lamp.on() 1sec/ 1sec/ FlashOff entry/lamp.off() Phase2 CommitDone Group transition 10
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 off/ FlashOn FlashOff Ordine delle azioni annidate Da fuori a dentro le azioni entry Da dentro a fuori le azioni exit U U1 entry: x(c) exit: y() entry: f() exit: g(a,b) first f() then x(c) A first y() then g(a,b) 42 Deferred Events Ordine delle Azioni: Caso Complesso 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. Deferred event off/ LampOff entry/lamp.off() off/defer LampOn entry/lamp.on() S1 exit/exs1 S11 exit/exs11 E/actE S2 entry/ens2 inits2 S21 entry/ens21 sequenza di esecuzione delle Azioni, in caso di triggering della transizione exs11 exs1 acte ens2 inits2 ens21 11
Ortogonalità Viste multiple simultanee sulla stessa entità age Child Adult Retiree Person financialstatus Poor 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 AND-States Combinazione di descrizioni multiple simultanee age financialstatus Child Poor Adult age financialstatus Retiree Child Rich Adult Poor Retiree Rich 12
AND-States Regioni Ortogonali - Semantica transition Tutte le regioni ortogonali reagiscono allo stesso evento, (in principo) simultaneamente. state legalstatus financialstatus initial pseudostate LawAbiding Poor robbank/ robbank/ conditional pseudostate and-states Outlaw Rich AND-States & Concorrenza Gli AND-states non sono necessariamente concorrenti Semantica degli AND-states tipicamente a interleaving Uso concettualmente errato dell ortogonalità Uso di regioni per modellare oggetti attivi independenti Person1 Person2 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. Person1 Child Adult Retiree Person2 Child Adult Retiree Soluzione: --> due istanze dello stesso oggetto attivo!!! 13
Catch22 sanitystatus Interazioni tra Regioni Tipicamente, attraverso variabli condivise o riferimenti a cambio di stato delle altre regioni. request Grounding/ Crazy entry/sane := false; (flying)/ Sane entry/sane := true; sane : Boolean flying : Boolean flightstatus Flying entry/flying := true; (~sane)/ Grounded entry/flying := false; (sane)/ 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 Fork e Join Transizioni verso/da regions ortogonali: age / Child Adult Retiree Staff Member Manager employee 55 14
Transizioni Complesse pseudostates fork S1 S S1_1 e2 S1_2 e5 join initial pseudostate history pseudostate A B e1 e5 S2_1 e3 S2_2 S2 conditional pseudostate e4 C terminal pseudostate Pseudostates History C Symbol or Symbol Name Branch Pseudostate (type of junction pseudostate) Symbol H Symbol Name (Shallow) History Pseudostate Ritorno a uno stato gerarchico già visitato deep /shallow history T * or or n Terminal or Final Pseudostate Synch Pseudostate H* (Deep) History Pseudostate Initial or Default Pseudostate suspend/ Diagnostic1 Diagnosing Diagnostic2 [g] Fork Pseudostate Join Pseudostate Junction Pseudostate Merge Junction Pseudostate (type of junction pseudostate) resume/ H* Step11 Step12 Step21 Step22 [g] Choice Point Pseudostate label Stub Pseudostate 15
Deep History Shallow History Synch Pseudostate Synch Pseudostate Data Processing 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 Waiting for Processing Logging Data Datum Data datasignal Synch Pseudostate with unbounded multiplicity synch state * User Monitoring Applying /active alarm ct = 0 Alarm Filters Idle Waiting to Process done tm(displaytime) Alarms alarmraised C [active alarm ct > 0]/ gensignal(alarmraised) Waiting to [else] accept /active alarm ct = 0 Displaying Alarms accept Alarm Processing 1 synch state 16
Stub Notation Abbreviazione notazionale: nessuna aggiunta semantica LampOff entry/lamp.off() flash/ LampFlashing stub state reference toon(mode: tmode) defaultmode = mode; Submachines: Reference Self Testing include / BITSubmachine device Test RAM Test On done(defaultmode) Operating include / OpsSubmachine dotest Normal Failsafe off/ FlashOn Off Abort doramtest dodevicetest [else] [recoverok] LampOn entry/lamp.on() FlashOff tooff Unrecoverable Error submachine indicator C errorfound errorhandled Submachines: Referenced Uso degli State Diagrams submachine stub state Testing ROM device Test Testing Components Logging Test Results BITSubmachine entry / iserror = false; done done Testing RAM errorfound/ iserror = true; C Abort [else] RAM Test [iserror == false] Normal OpsSubmachine (m: tmode) C Failsafe [else] Normal Mode [m == normal] Demo Mode [m == failsafe] Failsafe Mode tooff errorfound doramtest subend dotest Normal dodevicetest 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) 17
Formal Verification Development Cycle - 1 Natural Language Formalized Modelization Phase Architectural Design Detailed Design Software Requirements Document (Finite State) Model Architectural Design Document Detailed Design Document Coding Source code Formalization Phase Formal Verification Integration Test Unit Test Properties (formal expr. of Requirements) Test Case Generation Test Suite Functional test Formal Verification Development Cycle - 2 Model Driven Development Natural Language Formalized Modelization Phase Software Requirements Document (Finite State) Model Code Generation Source code Formalization Phase Formal Verification Properties (formal expr. of Requirements) Test Suite Test Case Generation Functional test Model Checking (Clarke/Emerson, Queille/Sifakis) - 1986 ACTL Formula in logica temporale p Modello a stati finiti AG([p] EF<q> true) q MC si algoritmo no p q q q Contro-esempio Il modello deve rappresentare tutti i comportamenti Specifica: relazioni tra Class Diagrams, Sequence Diagrams e State Diagrams Il diagramma delle classi definisce le relazioni tra le classi del sistema: alcune delle classi definissono oggetti passivi, altre oggetti attivi Il comportamento di ogni oggetto attivo viene specificato attraverso uno state diagram, associato alla relativa classe Un sequence diagram definisce un possibile schema di interazione (scenario) tra oggetti attivi o passivi, istanze di classi definite nel class diagram. 18
PBX Main Class Diagram PBX Connection Statechart PBX Line Statechart PBX Telephone Statechart 19
PBX Main? Call Connect Scenario (1 of 4) User? Credits Bruce Powel Douglass, Real-Time UML, Slides, Ilogix Gunnar Övergaard, Bran Selic, Conrad Bock, Behavioral Modeling, Modeling with OMG UML Tutorial Series, UML Revision Task Force, Nov. 2000 20