I nuovi arrivati al formalismo delle macchine a stati spesso confondono i diagrammi di stato con i diagrammi di flusso. La figura qui sotto mostra un confronto tra un diagramma di stato e un diagramma di flusso. Una macchina a stati (pannello (a)) esegue azioni in risposta a eventi espliciti. Al contrario, il diagramma di flusso (pannello (b)) non ha bisogno di eventi espliciti ma piuttosto di transizioni da nodo a nodo nel suo grafico automaticamente al completamento delle attività.
I nodi dei diagrammi di flusso sono bordi nel grafico indotto degli stati.Il motivo è che ogni nodo in un diagramma di flusso rappresenta un comando di programma.Un comando di programma è un’azione da eseguire.Quindi non è uno stato, ma quando viene applicato allo stato del programma, provoca una transizione ad un altro stato.
In dettaglio, il listato del codice sorgente rappresenta un grafo di programma.L’esecuzione del grafo di programma (parsing e interpretazione) provoca un grafo di stato.Quindi ogni grafo di programma induce un grafo di stato.La conversione del grafo di programma nel suo grafico di stato associato è chiamata “svolgimento” del grafo di programma.
Il grafo di programma è una sequenza di comandi.Se non esistono variabili, allora lo stato consiste solo nel contatore di programma, che tiene traccia di dove siamo nel programma durante l’esecuzione (qual è il prossimo comando da applicare).
In questo caso prima di eseguire un comando il contatore di programma è in una certa posizione (stato prima che il comando venga eseguito).Eseguendo il comando si sposta il contatore di programma al comando successivo.Poiché il contatore del programma è l’intero stato, ne consegue che l’esecuzione del comando ha cambiato lo stato, quindi il comando stesso corrisponde a una transizione tra i due stati.
Ora consideriamo il caso completo, quando le variabili esistono e sono influenzate dai comandi del programma che vengono eseguiti.Allora tra diverse posizioni del contatore del programma, non solo il contatore del programma cambia, ma anche le variabili possono cambiare valore, a causa dei comandi eseguiti.Di conseguenza, anche se rivisitiamo qualche comando del programma (per esempio in un ciclo), questo non implica che il programma sia nello stesso stato.
Nel caso precedente, il programma sarebbe nello stesso stato, perché l’intero stato è solo il contatore del programma, quindi se il contatore del programma punta alla stessa posizione (comando successivo) è sufficiente per specificare che siamo nello stesso stato.Tuttavia, se lo stato include le variabili, allora se queste cambiano valore, possiamo essere nella stessa posizione del programma con valori diversi delle variabili, cioè in uno stato diverso nello spazio di stato del programma.
Il termine “unfolding” ha origine da questa moltiplicazione delle posizioni quando si produce il grafico di stato dal grafico del programma.
Un esempio rappresentativo è un ciclo do che incrementa un contatore fino a quando non trabocca e diventa nuovamente 0.Anche se il ciclo do esegue lo stesso comando di incremento iterativamente, quindi il grafo del programma esegue un ciclo, nel suo spazio di stato non è un ciclo, ma una linea. Questo risulta dal fatto che lo stato è la locazione del programma (qui ciclico) combinato con il valore del contatore, che è strettamente crescente (fino all’overflow), quindi diversi stati sono visitati in sequenza, fino all’overflow.Dopo l’overflow il contatore diventa di nuovo 0, quindi lo stato iniziale viene rivisitato nello spazio di stato, chiudendo un ciclo nello spazio di stato (assumendo che il contatore sia stato inizializzato a 0).
La figura sopra tenta di mostrare questa inversione di ruoli allineando gli archi dei diagrammi di stato con le fasi di elaborazione del diagramma di flusso.
Si può paragonare un diagramma di flusso a una catena di montaggio nella produzione perché il diagramma di flusso descrive la progressione di qualche compito dall’inizio alla fine (es, trasformare l’input del codice sorgente in un output di codice oggetto da parte di un compilatore). Una macchina a stati generalmente non ha alcuna nozione di tale progressione. La macchina a stati della porta mostrata all’inizio di questo articolo, per esempio, non è in uno stadio più avanzato quando è nello stato “chiuso”, rispetto allo stato “aperto”; semplicemente reagisce in modo diverso agli eventi di apertura/chiusura. Uno stato in una macchina a stati è un modo efficiente di specificare un particolare comportamento, piuttosto che uno stadio di elaborazione.