Diagrammi di stato UML: visualizzare le sequenze degli stati degli oggetti
La redazione di IONOS
Nello sviluppo di un prodotto o nella programmazione di software i diagrammi di stato UML servono a raffigurare con immagini e in maniera comprensibile il ciclo di vita dei singoli oggetti. Questo tipo di diagramma, pur essendo costituito solo da pochi elementi, se utilizzato correttamente contribuisce in maniera decisiva al successo del prodotto finale. Scoprirete nei paragrafi seguenti perché e in quali casi questo diagramma è conveniente e come creare un vostro diagramma di stato UML.
Che cos’è un diagramma di stato?
Un diagramma di stato UML (detto anche diagramma di transizioni di stato, state diagram o state machine diagram) visualizza gli stati di un procedimento finito, dunque di un modello di comportamento costituito da azioni e stati o transizioni di stato. Inoltre il diagramma prevede per ogni oggetto del modello uno stato iniziale, uno stato finale e almeno uno stato intermedio. Il diagramma di stato consente di raffigurare l’intero ciclo di vita di un sistema o di una parte di sistema o di singoli componenti 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 componente 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 pubblicato nel 1987 nel testo scientifico “Statecharts: A Visual Formalism for Complex Systems”. Altri tipi di diagrammi UML sono ad esempio il diagramma dei casi d’uso e il diagramma dei componenti.
Quale è l’applicazione dei diagrammi di stato UML?
Come già citato, lo scopo dei diagrammi di stato è descrivere il più precisamente possibile il comportamento di un sistema. La rappresentazione grafica dei singoli processi alla fine dovrebbe essere in grado di rispondere, tra le altre, alle seguenti domande:
- Cosa succede se l’oggetto si trova in uno stato specifico?
- Quale stato deve verificarsi affinché l’oggetto modifichi il suo comportamento?
- Quali sono le azioni scatenanti?
- Quali proprietà deve avere l’oggetto per poter cambiare stato?
Pertanto, i diagrammi di stato UML vengono utilizzati in ogni situazione in cui è utile visualizzare stati e condizioni di transizione per un processo di sviluppo ottimizzato. Sono particolarmente diffusi ad esempio nella progettazione di sistemi integrati (Embedded Systems), poiché elaborano in background vari segnali e processi automatizzati, che devono essere coordinati in modo ottimale tra loro. In questo caso un diagramma di stato supporta gli sviluppatori visualizzando tutte le funzioni di controllo e regolamentazione rilevanti e rendendole immediatamente disponibili.
È facile spiegare i vantaggi dei diagrammi di stato con l’esempio della funzione “Acqua Stop” della lavatrice, che regola l’interruzione 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 rappresentazione grafica mostra in quale stato e in quali circostanze si applica il principio “Acqua Stop”.
In numerosi campi industriali come la tecnologia medica o il settore dei trasporti vengono impiegati diagrammi di stato per spiegare fatti complessi. I diagrammi di stato vengono utilizzati anche nella gestione del prodotto e del progetto, nonché nel Requirements Engineering.
Diagramma di stato: struttura e componenti in sintesi
Sebbene i diagrammi di stato UML si basino su pochi elementi, la combinazione intelligente di questi componenti rende facile mappare anche complesse sequenze di stato. Quali sono i componenti chiave e come appare la struttura di base di un diagramma di stato?
Stati
Gli stati sono i componenti centrali di un diagramma di stato. Tutti gli stati reali vengono sempre rappresentati con un rettangolo dagli angoli arrotondati. Una porta ad esempio può avere due valori di stato:
Richiamando l’esempio del diagramma di stato per rappresentare gli stati di una porta, deve sempre essere soddisfatta la seguente condizione:
- L’oggetto si trova sempre in uno dei rispettivi stati: quindi la porta è aperta o chiusa, ma mai contemporaneamente aperta e chiusa.
In diagrammi di stato più complessi il rettangolo può essere suddiviso in massimo tre zone, che rappresentano specifiche comportamentali (vedi transizione).
Transizione: come cambia uno stato?
Per passare da uno stato all’altro deve essere attivato un evento che rappresenta una transizione. Questo cambiamento di stato (transizione) collega gli stati uno all’altro ed è raffigurato visivamente con una freccia. Potrebbero esserci delle condizioni per l’attivazione di questa transizione. In linea di principio nei diagrammi di stato UML si differenzia tra transizioni interne ed esterne. Mentre le transizioni esterne sono obbligatorie nella creazione di un diagramma di stato, le transizioni interne non devono necessariamente 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 condizione che questa deve restare aperta almeno 5 secondi prima che lo stato passi da “aperto” a “chiuso”.
Transizione esterna: cambiamento di stato
Le transizioni, prese in considerazione nel seguente esempio di un diagramma di stato UML, sono le cosiddette transizioni esterne. In questo caso la transizione ha come conseguenza che l’oggetto passa in un altro stato (entry/exit).
Esempio: se l’allarme di una radiosveglia viene attivato, lo stato passerà da “allarme attivato” ad “allarme disattivato”. Lo stato cambia.
Transizione interna: stato immutato
Nella transizione interna non viene generato un cambiamento di stato ma un’attività.
Esempio: in un sistema di contabilità ad una fattura non pagata può seguire l’invio automatico di una fattura (transizione esterna). Se come reazione ad un mancato pagamento viene inviato un sollecito, allora si tratta di una transizione interna. Sebbene vi sia un’attività “invio del sollecito”, la fattura rimane nello stato “non pagato” fino a nuovo avviso.
Eventi: perché gli stati cambiano?
Gli eventi (Actions) possono descrivere in modo più dettagliato le circostanze in cui uno stato viene abbandonato per passare a quello successivo. Ciò non è necessario quando si passa dallo stato iniziale al primo stato reale, ulteriori informazioni sull’evento sono facoltative. Se non viene specificato alcun evento, ciò significa che il nuovo stato subentra automaticamente non appena tutte le attività negli stati precedenti sono state completate.
Un “non evento” (trigger/ANY-trigger) significa che l’evento è in linea di massima sempre presente. Gli eventi possono essere designati come specifica comportamentale all’interno dello stato o all’interno della transizione di stato (vedi transizione).
Un evento scatenante deve soddisfare le tre seguenti condizioni:
- entry: l’evento viene attivato automaticamente quando si entra in uno stato, ovvero in tutte le transizioni in entrata.
- exit: l’evento viene attivato quando si abbandona uno stato, ovvero in tutte le transizioni in uscita.
- do: l’evento viene attivato ripetutamente se lo stato non viene modificato.
Queste specifiche comportamentali possono essere annotate all’interno dello stato per mostrare in maniera semplificata i comportamenti in base ai quali lo stato cambia. Esistono due opzioni per la rappresentazione grafica di questi trigger; innanzitutto potrebbero essere indicati all’interno del rispettivo stato, come evidenzia il seguente esempio di diagramma di stato:
In alternativa gli eventi possono essere indicati con la freccia di transizione:
Pseudo stati
Se gli elementi di controllo influenzano il funzionamento di una macchina a stati, ma non hanno assegnazioni 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 transizione in entrata ed esattamente una in uscita che rivela lo stato iniziale
- Stato finale (ingl. final): nessuna transizione in uscita, fine della sequenza di comportamento
- Forchetta (ingl. fork): suddivisione in più stati paralleli
- Sincronizzazione (ingl. join): uniformazione di più stati paralleli
- Giunzione (ingl. junction): snodo per il collegamento in serie di più transizioni
- Scelta (ingl. choice): nodo da cui possono iniziare diverse transizioni alternative basate su una decisione precedentemente presa
- Punto d’entrata (ingl. entry point): concentrazione di transizioni simili, che entrano in uno stato composito
- Punto di uscita (ingl. exit point): concentrazione di transizioni simili, che escono da uno stato composito
- Storia superficiale (ingl. shallow history): memorizzazione dell’ultimo sottostato attivo di uno stato composito
- Storia profonda (ingl. deep history): memorizzazione dell’ultimo sottostato attivo di tutti i livelli della gerarchia di uno stato composito
Particolarità: diagramma secondario
A seconda della complessità sono possibili sottostati che forniscono un quadro dettagliato dello stato dell’oggetto e del possibile comportamento. Queste spiegazioni più complesse nei diagrammi di stato UML sono la regola, in particolare nei contesti tecnici.
- composite state: qui uno stato può essere definito in modo più approfondito.
Esempio: una porta può trovarsi nello stato “aperto” e “chiuso”. I sottostati dello stato “chiuso” potrebbero essere “sbloccato” o “bloccato”.
- submachine state: qui un diagramma di stato secondario viene aggiunto a uno stato. I sottostati costituiti da più stati secondari sono chiamati stati complessi. I vari stati secondari possono essere gestiti indipendentemente l’uno dall’altro, ma possono anche essere collegati tra loro.
Esempio: in uno smartphone la funzione sveglia è solo una delle tante funzioni alle quali è possibile collegare più stati. Se sono programmati più allarmi per diversi giorni della settimana e orari, questi sono stati secondari, che funzionano indipendentemente l’uno dall’altro.
Creare un diagramma di stato: esempio di un diagramma di stato semplice
Un diagramma di stato può essere applicato a una vasta gamma di oggetti. Nell’esempio seguente i vari elementi devono essere presentati utilizzando la rappresentazione grafica degli stati di una fattura. Gli elementi chiave di un diagramma di stato UML vengono raffigurati come segue:
Il diagramma semplice, assemblato e rapportato all’esempio, si presenta così:
Dopo il punto di partenza, come pseudo stato la fattura si trova nello stato “scritto” (written). Nel migliore dei casi segue la transizione allo stato “pagato” (paid). Questa transizione può essere descritta in modo più dettagliato aggiungendo il nome dell’evento “inviare”.
Una volta che la fattura è stata pagata, essa si trova nello stato “pagato”. Prima di raggiungere questo stato potrebbe essere necessario inviare un “sollecito” (reminder). Poiché in questo caso la fattura non cambia lo stato, ma si tratta di un’attività, è una transizione interna. Se la fattura non verrà pagata verranno inviati fino a tre solleciti.
