Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
I corsi di Scienze Matematiche Fisiche e Naturali
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Sergio Di Martino » 12.UML: Gli StateCharts


Obiettivi della lezione

Comprendere il formalismo degli statecharts in UML

Software Lifecycle Activities

Software Lifecycle Activities.

Software Lifecycle Activities.


Diagrammi di stato

Un Diagramma di Stato è un formalismo grafico largamente utilizzato in computer science per rappresentare il comportamento di un artefatto (oggetto, modulo, intero sistema, etc…) composto da un numero finito di stati.

Ne esistono svariate versioni

  • deterministic finite state machine (DFA);
  • nondeterministic finite state machine (NFA);
  • Moore machine;
  • Harel’s StateCharts;

Stati e transizioni

Paradigma ben noto e molto comprensibile per descrivere il comportamento di entità dinamiche

  • stati rilevanti dell’entità;
  • transizioni = possibili passaggi di stati, magari con annotazioni riguardo a cosa ha causato la transizione, o che cosa viene rilevato sulla transizione.

Vantaggio principale: grande impatto visuale, molto leggibile, per modellare aspetti dinamici e transienti.

Stati e transizioni.

Stati e transizioni.


Statechart

Notazione visuale e formale, sviluppata da D. Harel, fine anni 80, per descrive il comportamento di sistemi reattivi.

  • Le transizioni descrivono come l’entità modellata “reagisce” a eventi (generati dall’esterno o da se stesso).
  • Le transizioni sono (in genere) lanciate (triggered) dagli eventi.

Statechart diagram di UML: adattamento delle statechart ad un mondo O-O

Usati principalmente per descrivere il comportamento di:

  • Use Cases;
  • Classi;

Definizione di Statechart Diagrams, secondo le specifiche UML

  • Uno statechart può essere usato per descrivere il comportametno di un elmento di un modello, come un oggetto o un’interazione. In particolare, descrive possibili sequenze di stati e le azioni attraverso cui l’elemento può procedere durante la sua vita, come risultato di reazioni ad eventi discreti (es: segnali, invocazioni di metodi, etc…).
  • Gli statecharts rappresentano il comportamento di entità che esibiscono un comportamento dinamico, specificandone la risposta a ricezioni di eventi. Tipicamente questo tipo di diagramma è usato per descrivere il comportamento di classi, ma gli statecharts possono anche descrivere il comportamento di altre entità di modelli, quali casi d’uso, attori, metodi, ecc…

A cosa servono gli statechart diagram?

Ogni oggetto in un sistema ha un certo ciclo di vita. Tra la sua creazione e la sua distruzione esso interagisce con gli oggetti vicini.

L’oggetto quindi dovrà rispondere a stimoli asincroni che gli arrivano dal suo ambiente.

Es.: un cellulare deve essere sempre pronto a rispondere a chiamate in entrata

Esistono oggetti il cui comportamento dipende dallo stato dei suoi attributi

Es.: in un cellulare, all’arrivo di una chiamata l’attivarsi o meno della suoneria dipende dalla modalità (normale o “silenziosa”) in cui si trova l’apparecchio.

Il ciclo di vita di questi artefatti (che spesso sono classi, ma possono essere anche interi sottosistemi) viene modellato attraverso Statecharts.

Uno Statechart di design è quindi un diagramma chiave per guidare i programmatori nell’implementazione del sistema.
Tutto ciò che c’è nello statechart di design è un comportamento da implementare.

Il Formalismo  - Eventi, Stati e Transizioni

Un Evento è un avvenimento significativo per un artefatto.
Uno Stato è una condizione di un oggetto in un intervallo di tempo compreso tra due eventi.

  • Uno stato è una situazione nella vita dell’oggetto in questione in cui esso soddisfa una qualche condizione, esegue una qualche attività o è in attesa di un qualche evento.

Una Transizione è una relazione che lega uno stato di partenza ed uno stato di arrivo (non necessariamente distinti).

  • Le transizioni che riportano nello stesso stato sono dette self-transition.

Rappresentazioni in UML

Stato

  • Un rettangolo arrotondato.
  • Un nome.
  • Un elenco opzionale di operazioni da svolgere al suo interno.

Ogni transizione è etichettata con tre elementi, tutti opzionali

Evento [Condizione] / Azione

Evento (trigger): è l’occorrenza di uno stimolo che può innescare una transizione fra stati

Es: NextTrackButtonPressed()

Rappresentazione dell Stato in UML.

Rappresentazione dell Stato in UML.


Rappresentazioni in UML (segue)

Condizione (guard): espressione booleana.

  • Se da uno stato escono più transizioni, le loro condizioni devono essere mutuamente esclusive
  • Può essere espressa usando OCL, linguaggi di programmazione, pseudocodice….
  • Es: [This.CurrentTrack < This.TotalTracks]

Azione: è associata alla transizione, è considerata un processo rapido, non interrompibile da un evento (atomica)

Es: This.CurrentTrack++

Rappresentazione dell Stato in UML.

Rappresentazione dell Stato in UML.


Stato: notazione

Uno stato può opzionalmente avere le seguenti azioni:

  • Entry: azione eseguita ogni volta che si entra nello stato (cioè in risposta all’evento entry ).
  • Exit: azione eseguita ogni volta che si lascia lo stato (cioè in risposta all’evento exit ).
  • Do: è associata allo stato, può prevedere un lasso di tempo considerevole, e può essere interrotta da un evento (non-atomica).

Esistono due stati particolari: stato iniziale e stato finale.
Il primo è il punto di partenza del diagramma ed il secondo è il punto di arrivo.

Negli statechart diagram che modellano il comportamento di sistemi destinati a girare di continuo (per esempio sistemi embedded) lo stato finale può non essere presente.

Esempio behaviour dei tornei: Definire la classe Torneo, ed eventuali altre, in modo che gli eventi, le espressione e le azioni che appaiono nella statechart sopra siano ben definite.

Esempio di stato.

Esempio di stato.

Esempio: behaviour dei tornei.

Esempio: behaviour dei tornei.


Stato: notazione (segue)

Una transizione che non abbia nessun evento ad innescarla è detta triggerless.

Al termine delle Do Actions di A si passa automaticamente nello stato B.

E’ il termine dell’attività ad innescare la transizione fra stati.

 

Transizioni triggerless.

Transizioni triggerless.


Sottostati e Stati composti

Il comportamento di uno stato può essere modellato anch’esso con una macchina a stati e questo a qualsiasi livello di profondità:

  • può migliorare molto la leggibilità del diagramma, ma…
  • troppi livelli penalizzano la leggibilità del diagramma!

Uno stato composito (cioè che contiene sottostati) può possedere entry, do ed exit action, con lo stesso significato che essi hanno negli stati semplici.

Una transizione che parte da un superstato rappresenta una transizione da ogni sottostato.

Uno stato può essere decomposto:

  • ortogonalmente (in sottostati mutuamente esclusivi);
  • concorrentemente (in sottostati concorrenti).

SottoStati Ortogonali

Uno stato può essere decomposto (strutturato) dettagliando cosa fa l’entità modellata quando è in quello stato.

La decomposizione di uno stato si può riportare a parte (ne migliora la leggibilità).

Sono ammesse anche transizioni che entrano direttamente in uno stato interno.

Stato Ortogonale.

Stato Ortogonale.

Esempio.

Esempio.


SottoStati Concorrenti

Uno stato può essere decomposto concorrentemente (in sottostati paralleli):

  • OK in fase di analisi (può semplificare le cose);
  • in fase di design richiede molta attenzione (sistema multiprocessore?).
Stato Concorrente.

Stato Concorrente.

Esempio.

Esempio.


History states

In generale quando, per effetto di una transizione, si entra in uno stato composito, la state machine innestata comincia dal suo stato iniziale (a meno che la transizione non specifichi come target uno specifico sottostato).

Esistono però situazioni in cui vorremmo poter memorizzare quale sottostato era attivo nel momento in cui si abbandona uno stato composito.

Lo scopo è quello di riprendere da quel punto le attività una volta che si rientri nello stato composito.

Esempio: History states.

Esempio: History states.


H e H*

Lo stato H è detto history state superficiale. Infatti in caso di state machine innestate a più di un livello ricorda soltanto lo stato del primo livello (cioè quello in cui si trova) mentre gli altri livelli ripartono dallo stato iniziale.

Se si vuole ricordare lo stato di ogni livello, esiste uno history state profondo, cioè H*.
Con l’uso di H* ci si assicura che tutte le state machine ad ogni livello sottostante a quello con H* ricordino lo stato in cui si trovavano all’abbandono dello stato composito complessivo.

Ovviamente in caso di macchine innestate ad un solo livello H e H* sono equivalenti.

Linee guida per gli statecharts (def. stati)

Il nome dello stato deve riflettere un intervallo di tempo reale.

Dare nomi significativi agli stati:

  • se questo non è possibile significa che c’è qualche problema nel progetto;
  • pensare alle successive necessità di manutenzione!

Il nome dello stato deve essere unico.

Deve essere possibile uscire da ogni stato.

Attivazione dei sottostati in base al tipo di scomposizione.

Linee guida per gli statecharts (azioni e eventi)

Non confondere evento (causa) con azione (effetto).

Nomi di eventi e azioni non ambigui.

Condizioni sugli eventi hanno valore booleano.

Azioni e condizioni sono opzionali: da usare solo se necessario.

Check finale: abbiamo descritto TUTTI i comportamenti possibili del sistema?

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion