Diagrammi di stato UML: vi­sua­liz­za­re le sequenze degli stati degli oggetti

Nello sviluppo di un prodotto o nella pro­gram­ma­zio­ne di software i diagrammi di stato UML servono a raf­fi­gu­ra­re con immagini e in maniera com­pren­si­bi­le il ciclo di vita dei singoli oggetti. Questo tipo di diagramma, pur essendo co­sti­tui­to solo da pochi elementi, se uti­liz­za­to cor­ret­ta­men­te con­tri­bui­sce in maniera decisiva al successo del prodotto finale. Sco­pri­re­te nei paragrafi seguenti perché e in quali casi questo diagramma è con­ve­nien­te e come creare un vostro diagramma di stato UML.

Un diagramma di stato UML (detto anche diagramma di tran­si­zio­ni di stato, state diagram o state machine diagram) vi­sua­liz­za gli stati di un pro­ce­di­men­to finito, dunque di un modello di com­por­ta­men­to co­sti­tui­to da azioni e stati o tran­si­zio­ni di stato. Inoltre il diagramma prevede per ogni oggetto del modello uno stato iniziale, uno stato finale e almeno uno stato in­ter­me­dio. Il diagramma di stato consente di raf­fi­gu­ra­re l’intero ciclo di vita di un sistema o di una parte di sistema o di singoli com­po­nen­ti o classi, non importa se si tratta ad esempio dei processi di una macchina per il caffè, di un lettore di e-book o di un com­po­nen­te tecnico di un veicolo.

Il diagramma di stato è uno dei 14 tipi di diagramma dell’Unified Modeling Language (UML) e del Systems Model Language (SysML). Risale a un progetto di David Harel, da lui pub­bli­ca­to nel 1987 nel testo scien­ti­fi­co “Sta­te­charts: A Visual Formalism for Complex Systems”. Altri tipi di diagrammi UML sono ad esempio il diagramma dei casi d’uso e il diagramma dei com­po­nen­ti.

Come già citato, lo scopo dei diagrammi di stato è de­scri­ve­re il più pre­ci­sa­men­te possibile il com­por­ta­men­to di un sistema. La rap­pre­sen­ta­zio­ne grafica dei singoli processi alla fine dovrebbe essere in grado di ri­spon­de­re, tra le altre, alle seguenti domande:

• Cosa succede se l’oggetto si trova in uno stato specifico?
• Quale stato deve ve­ri­fi­car­si affinché l’oggetto modifichi il suo com­por­ta­men­to?
• Quali sono le azioni sca­te­nan­ti?
• Quali proprietà deve avere l’oggetto per poter cambiare stato?

Pertanto, i diagrammi di stato UML vengono uti­liz­za­ti in ogni si­tua­zio­ne in cui è utile vi­sua­liz­za­re stati e con­di­zio­ni di tran­si­zio­ne per un processo di sviluppo ot­ti­miz­za­to. Sono par­ti­co­lar­men­te diffusi ad esempio nella pro­get­ta­zio­ne di sistemi integrati (Embedded Systems), poiché elaborano in back­ground vari segnali e processi au­to­ma­tiz­za­ti, che devono essere coor­di­na­ti in modo ottimale tra loro. In questo caso un diagramma di stato supporta gli svi­lup­pa­to­ri vi­sua­liz­zan­do tutte le funzioni di controllo e re­go­la­men­ta­zio­ne rilevanti e ren­den­do­le im­me­dia­ta­men­te di­spo­ni­bi­li.

È facile spiegare i vantaggi dei diagrammi di stato con l’esempio della funzione “Acqua Stop” della lavatrice, che regola l’in­ter­ru­zio­ne della fornitura d’acqua. Come parte di un diagramma di stato UML, questa funzione può essere intesa come un sistema separato. In questo caso la rap­pre­sen­ta­zio­ne grafica mostra in quale stato e in quali cir­co­stan­ze si applica il principio “Acqua Stop”.

Sebbene i diagrammi di stato UML si basino su pochi elementi, la com­bi­na­zio­ne in­tel­li­gen­te di questi com­po­nen­ti rende facile mappare anche complesse sequenze di stato. Quali sono i com­po­nen­ti chiave e come appare la struttura di base di un diagramma di stato?

Ri­chia­man­do l’esempio del diagramma di stato per rap­pre­sen­ta­re gli stati di una porta, deve sempre essere sod­di­sfat­ta la seguente con­di­zio­ne:

• L’oggetto si trova sempre in uno dei ri­spet­ti­vi stati: quindi la porta è aperta o chiusa, ma mai con­tem­po­ra­nea­men­te aperta e chiusa.

In diagrammi di stato più complessi il ret­tan­go­lo può essere suddiviso in massimo tre zone, che rap­pre­sen­ta­no spe­ci­fi­che com­por­ta­men­ta­li (vedi tran­si­zio­ne).

Per passare da uno stato all’altro deve essere attivato un evento che rap­pre­sen­ta una tran­si­zio­ne. Questo cam­bia­men­to di stato (tran­si­zio­ne) collega gli stati uno all’altro ed è raf­fi­gu­ra­to vi­si­va­men­te con una freccia. Po­treb­be­ro esserci delle con­di­zio­ni per l’at­ti­va­zio­ne di questa tran­si­zio­ne. In linea di principio nei diagrammi di stato UML si dif­fe­ren­zia tra tran­si­zio­ni interne ed esterne. Mentre le tran­si­zio­ni esterne sono ob­bli­ga­to­rie nella creazione di un diagramma di stato, le tran­si­zio­ni interne non devono ne­ces­sa­ria­men­te far parte del diagramma.

Nel diagramma di stato di un ascensore può ad esempio essere indicata per l’azione “chiudere la porta dell’ascensore” la con­di­zio­ne che questa deve restare aperta almeno 5 secondi prima che lo stato passi da “aperto” a “chiuso”.

Se gli elementi di controllo in­fluen­za­no il fun­zio­na­men­to di una macchina a stati, ma non hanno as­se­gna­zio­ni di valore, nei diagrammi di stato UML vengono indicati come pseudo stati. UML 2, l’attuale versione di Unified Modeling Language, conosce dieci diversi di questi pseudo stati:

• Stato iniziale (ingl. initial): nessuna tran­si­zio­ne in entrata ed esat­ta­men­te una in uscita che rivela lo stato iniziale
• Stato finale (ingl. final): nessuna tran­si­zio­ne in uscita, fine della sequenza di com­por­ta­men­to
• Forchetta (ingl. fork): sud­di­vi­sio­ne in più stati paralleli
• Sin­cro­niz­za­zio­ne (ingl. join): uni­for­ma­zio­ne di più stati paralleli
• Giunzione (ingl. junction): snodo per il col­le­ga­men­to in serie di più tran­si­zio­ni
• Scelta (ingl. choice): nodo da cui possono iniziare diverse tran­si­zio­ni al­ter­na­ti­ve basate su una decisione pre­ce­den­te­men­te presa
• Punto d’entrata (ingl. entry point): con­cen­tra­zio­ne di tran­si­zio­ni simili, che entrano in uno stato composito
• Punto di uscita (ingl. exit point): con­cen­tra­zio­ne di tran­si­zio­ni simili, che escono da uno stato composito
• Storia su­per­fi­cia­le (ingl. shallow history): me­mo­riz­za­zio­ne dell’ultimo sot­to­sta­to attivo di uno stato composito
• Storia profonda (ingl. deep history): me­mo­riz­za­zio­ne dell’ultimo sot­to­sta­to attivo di tutti i livelli della gerarchia di uno stato composito

A seconda della com­ples­si­tà sono possibili sot­to­sta­ti che for­ni­sco­no un quadro det­ta­glia­to dello stato dell’oggetto e del possibile com­por­ta­men­to. Queste spie­ga­zio­ni più complesse nei diagrammi di stato UML sono la regola, in par­ti­co­la­re nei contesti tecnici.

• composite state: qui uno stato può essere definito in modo più ap­pro­fon­di­to.

Esempio: una porta può trovarsi nello stato “aperto” e “chiuso”. I sot­to­sta­ti dello stato “chiuso” po­treb­be­ro essere “sbloccato” o “bloccato”.

• sub­ma­chi­ne state: qui un diagramma di stato se­con­da­rio viene aggiunto a uno stato. I sot­to­sta­ti co­sti­tui­ti da più stati secondari sono chiamati stati complessi. I vari stati secondari possono essere gestiti in­di­pen­den­te­men­te l’uno dall’altro, ma possono anche essere collegati tra loro.

Esempio: in uno smart­pho­ne la funzione sveglia è solo una delle tante funzioni alle quali è possibile collegare più stati. Se sono pro­gram­ma­ti più allarmi per diversi giorni della settimana e orari, questi sono stati secondari, che fun­zio­na­no in­di­pen­den­te­men­te l’uno dall’altro.

Dopo il punto di partenza, come pseudo stato la fattura si trova nello stato “scritto” (written). Nel migliore dei casi segue la tran­si­zio­ne allo stato “pagato” (paid). Questa tran­si­zio­ne può essere descritta in modo più det­ta­glia­to ag­giun­gen­do il nome dell’evento “inviare”.

Una volta che la fattura è stata pagata, essa si trova nello stato “pagato”. Prima di rag­giun­ge­re questo stato potrebbe essere ne­ces­sa­rio inviare un “sollecito” (reminder). Poiché in questo caso la fattura non cambia lo stato, ma si tratta di un’attività, è una tran­si­zio­ne interna. Se la fattura non verrà pagata verranno inviati fino a tre solleciti.