05 Uml

Automation
Robotics and
System
CONTROL Università degli Studi
di Modena e Reggio Emilia
Automazione Industriale
5 - Il linguaggio descrittivo UML
Cesare Fantuzzi (cesare.fantuzzi@unimore.it)
Ingegneria Meccatronica
Ingegneria della Gestione Industriale
AA 2010/2011
Automation
Robotics and
System
Nota: il materiale didattico è adattato dal materiale sviluppato in

collaborazione con Marcello Bonfè (marcello.bonfe@unife.it),
dell’Università di Ferrara.
UNIFIED MODELING
LANGUAGE
Settembre - Dicembre Automazione Industriale - 5. UML 2
2010
Analisi e Progettazione
‫ ּס‬Analisi: studio di cosa deve fare il sistema e come esso è
composto (dal punto di vista “logico”)
‫ ּס‬Progettazione: studio di come implementare il sistema
(dal punto di vista “tecnico”)
‫ ּס‬Nel ciclo di ciclo di sviluppo e con l’approccio OO, la
distinzione tra le due attività può essere sottile: analizzare i
requisiti funzionali significa anche identificare possibili
oggetti e classi concettuali (base della progettazione
dettagliata)
‫ ּס‬Il punto cruciale è definire dei metodi adeguati per la
descrizione delle specifiche risultanti sia dall’analisi che
dalla progettazione (relazioni tra classi, interazioni,
struttura del sistema, comportamento, ecc.)
2010
Importanza dei metodi
descrittivi
‫ ּס‬I metodi di Ingegneria del Software hanno l'obiettivo di
fornire al progettista strumenti indipendenti dai
linguaggi di programmazione per strutturare
l’applicativo.
‫ ּס‬Questi strumenti devono permettere di fare fronte alla
complessità dei problemi, utilizzando solo i concetti
caratteristici dell’approccio progettuale, piuttosto che i
costrutti del linguaggio usato per l’implementazione.
‫ ּס‬Tali strumenti sono i linguaggi descrittivi (di specifica)
con i quali ottenere le Descrizioni concettuali (Modelli)
per l’analisi e la progettazione.

2010
Perché è necessario un
modello grafico?
‫ ּס‬Per comprendere al meglio le specifiche di progetto.
‫ ּס‬Per comprendere al meglio ed il prima possibile
eventuali criticità.
‫ ּס‬Per evitare errori ed omissioni nella analisi dei requisiti
del committente.
‫ ּס‬Per facilitare le comunicazioni fra il team di progetto.
‫ ּס‬Per sviluppare un piano di test e validazione.
‫ ּס‬Per documentare il progetto.

2010
Caratteristiche di un
linguaggio di specifica
‫ ּס‬Un linguaggio di specifica deve essere:
– Intuitivo, semplice da usare e da comprendere...
– ... ma Formale e non ambiguo (sintassi e semantica ben
definite)
– Indipendente dal linguaggio target...
– ... ma adattabile al contesto applicativo
– Standardizzato (e realmente usato!)
– Supportato da strumenti software (CASE) efficienti e
facilmente usabili.

2010
Un linguaggio per la
progettazione OO: UML
‫ ּס‬Tra gli anni 70’ e 90’ sono state proposti molti metodi di
analisi e progettazione (Booch, Object Modeling o OMT
Schaler/Mellor, etc.), e linguaggi di specifica.
‫ ּס‬Le numerose similitudini tra questi linguaggi hanno fatto
nascere l’esigenza di una standardizzazione.
‫ ּס‬Standard: Unified Modeling Language pubb.da OMG
(Object Management Group).
http://www.uml.org/

2010
Primo… cosa è UML?
‫ ּס‬La specifica OMG definisce UML come:
“The Unified Modeling Language (UML) is a graphical

language for visualizing, specifying, constructing, and
documenting the artifacts of a software-intensive system.
The UML offers a standard way to write a system's
blueprints, including conceptual things such as business
processes and system functions as well as concrete
things such as programming language statements,
database schemas, and reusable software components."

2010
Che cosa NON è UML
‫ ּס‬Lo UML non è un linguaggio di programmazione

visuale.
‫ ּס‬UML non è un processo di sviluppo.
– Non fornisce direttive su come fare evolvere un progetto
software.

2010
UML (Unified Modeling
Language)
‫ ּס‬Linguaggio interamente visuale (basato su una sintassi

grafica).
‫ ּס‬I diagrammi UML consentono di catturare le specifiche di
progetto da “diversi punti di vista”:
– Requisiti funzionali => Requirement Capture.
– Classificazione e relazioni tra gli oggetti => Object
structure.
– Comportamento degli oggetti => Object behaviour

2010
I diagrammi dello UML

2010
I diagrammi dello UML
‫ ּס‬Descrizione requisiti: (1) Use Case Diagrams

‫ ּס‬Struttura statica dell’applicativo: (2) Class diag.
‫ ּס‬Comportamento dinamico (individuale): (3) Statechart
diag.
‫ ּס‬Comportamento di interazione: (4)Collaboration, (5)
Sequence and (6) Activity diag.
‫ ּס‬Architettura implementativa: (7) Component and (8)
Deployment diag.

2010
Automation
Robotics and
System
Un caso d’uso (USE CASE) rappresenta una funzionalità completa

così come viene percepita da un attore che interagisce con il
sistema.
USE CASE DIAGRAMS

2010
Use case diagram

2010
Cattura dei requisiti: Use
Case diagrams
‫ ּס‬Definisce un comportamento coerente senza rivelare
la struttura interna del sistema.
‫ ּס‬Il comportamento viene definito attraverso la descrizione
di un “caso d’uso” del sistema.
‫ ּס‬Il caso d’uso e’ attivato da un “utente del sistema” o
“Attore”.
‫ ּס‬L’utente e’ una qualunque entità che interagisce con il
sistema che si vuole progettare.
‫ ּס‬Gli Use Case Diagrams sono quindi il punto di partenza
del processo di sviluppo (Requirements analysis)

2010
Elementi degli Use Case
diag.

2010
Un esempio: cella
robotizzata.
Il robot deve prelevare
materiale dalla cella di
stoccaggio del materiale
grezzo e collocarlo nella
cella di lavorazione. I
sistemi di controllo remoto
(sistema gestionale o
controllore locale) inviano il
comando di start e
rimangono in attesa della
fine del ciclo di lavoro
(stop). L’utente può
richiedere l’esecuzione di un
ciclo di lavoro.

2010
Elementi del diagramma:
Generalizzazione/Specializzazione

2010
Elementi del diagramma:
Inclusione

2010
Relazioni tra i Casi d’Uso
‫ ּס‬Generalizzazione/Specializzazione: questa relazione è

analoga a quella fra una classe base e una derivata,
cioè il caso d’uso “specializzato” dovrebbe “ereditare” le
caratteristiche di quello base ed eventualmente
ridefinirne alcune.
‫ ּס‬Inclusione (Include): è una relazione del tipo
client/server fra casi d’uso, cioè una funzionalità comune
viene “sfruttata” per realizzare altri casi d’uso.
– E’ equivalente alla chiamata di una procedura.

2010
Relazioni tra i Casi d’Uso (cont.)
‫ ּס‬Graficamente, la generalizzazione è raffigurata da

una freccia continua con punta triangolare,
l’inclusione con una freccia tratteggiata e la notazione
testuale <<include>>:
Settembre - Dicembre 2010 Automazione Industriale - 21

5. UML
Scomposizione gerarchica dei
“casi d’uso”
‫ ּס‬Gli Use Case Diagrams prevedono sempre un sistema e

gli attori esterni, perciò si possono considerare anche
“diagrammi di contesto” (Context Diagrams)
‫ ּס‬Tuttavia, può essere utile già a livello di definizione dei
requisiti, identificare una scomposizione del sistema
globale in sotto-sistemi distinti, descrivendo per ognuno
di essi una vista dei Casi d’Uso.
‫ ּס‬Ovviamente, ogni sotto-sistema avrà la sua “bounding
box” e interagirà con degli attori che possono essere gli
stessi del diagramma di contesto globale più gli altri
sotto-sistemi

2010
Un esempio: un sistema
Azienda
Sistema
Distribuisci azienda
dividendi
Azionista Acquista Acquirente

merci
Paga
tasse
Acquista materie
prime
Stato
Fornitore
2010
Un esempio: un sistema Azienda
(cont.)

2010
Un esempio: un sistema
Azienda (cont.)
Sistema
vendite
Sistema Acquirente
produzione
Sistema
amministrazione
2010
Come descrivere i “casi
d’uso”?
‫ ּס‬I casi d’uso definiscono una vista statica delle specifiche.
‫ ּס‬Il comportamento del caso d’uso (vista dinamica) è definito
con descrizioni testuali o con altri diagrammi UML (es.
Sequence Diagrams, State Diagrams, etc.)
‫ ּס‬Possiamo collegare agli Use Case Diag le info:
– documenti “informali” scambiati con il cliente.
– i requisiti non funzionali a quelli funzionali (es. vincoli
sulle prestazioni, elenco messaggi ed eventi scambiati
con l’utente).
– descrizioni più dettagliate (es. con Sequence Diagrams)
di scenari base (funzionamento normale) e alternativi
(funzionamento anomalo), da usare per i test di
validazione.
2010
Flusso delle attività (esempio)
Caso d’uso: “Afferra pezzo grezzo”
‫ ּס‬Precondizione: Il braccio deve essere collocato sul pezzo.
‫ ּס‬Flusso di attività (passi):
1. Apri pinza
2. Scendi sul pezzo
3. Chiudi pinza
4. Sali in posizione di volo
‫ּס‬ Postcondizione: Braccio collocato sul pezzo, pezzo
afferrato.

2010
Descrizione del Flusso delle
attività
‫ ּס‬Il flusso delle attività viene descritto da una sequenza di
passi che debbono essere eseguiti per implementare la
funzionalità.
‫( ּס‬Opzionale):
– Le precondizioni, cioè quale è la condizione del sistema
prima che sia eseguito il caso d’uso.
– Le postcondizioni, cioè le condizioni del sistema dopo che è
eseguito il caso d’uso.

2010
Il ruolo dei “casi d’uso” nella
cattura delle specifiche
‫ ּס‬L’analisi delle descrizioni testuali associate ai Casi d’Uso
permette di identificare gli elementi concettuali candidati a
diventare oggetti, classi, relazioni ed operazioni da
implementare
‫ ּס‬Linee guida per l’analisi dei Casi d’Uso:
– identificare i Casi d’Uso evidenziando i verbi “attivi” riferiti
al sistema nei documenti di specifica del committente
– identificare per ogni Caso d’Uso gli attori e le possibili
sequenze di eventi
– identificare oggetti e classi evidenziando i nomi nella
descrizione testuale di ogni Caso d’Uso (NB: un oggetto
può partecipare a più Casi d’Uso)
2010
Automation
Robotics and
System
Il Diagramma delle Classi descrive la struttura statica del sistema.
CLASS DIAGRAMS

2010
Definizione di classe
‫ ּס‬Aristotele: Tutti gli esseri viventi (oggetti) sebbene unici,

appartengono a determinati insiemi (classi) caratterizzati
dal possedere
– Le stesse caratteristiche e
– Lo stesso comportamento
‫ ּס‬Tutti gli oggetti sono “istanze” di classi.
‫ ּס‬La classe è una entità che consente di descrivere
formalmente proprietà e comportamento di una categoria
di oggetti simili.

2010
Relazione tra oggetti e classi
‫ ּס‬La relazione tra

Classe e Oggetto è
analoga a quella tra
Tipo e Variabile

2010
Elementi fondamentali di un
oggetto.
‫ ּס‬Un oggetto possiede

– Uno stato
– Un comportamento
– Una identità
‫ ּס‬La struttura e il comportamento di oggetti simili sono
definiti nella loro classe comune; i termini di istanza e
oggetto sono intercambiabili [Grady Booch]

2010
Sintassi della classe

2010
Classe e oggetto
Metodo (operazione)
Nome della classe
Attributi (dati)
Class Name Object Name : Class

Attribute type = 'Value'
attribute:Type =initialValue
operation(arg list):return type
Classe Oggetto

2010
Attributi
‫ ּס‬Gli attributi sono specificati da espressioni testuali nella
forma:
Visibilità Nome : DataType [Molteplicità] = Valore iniziale
dove Visibilità può essere indicata con il nome o con un

simbolo standard:
+ public
# protected
– private
~ package (v. seguito per la definizione di Package)
‫ ּס‬La molteplicità è un concetto simile a quello della
dimensione di un array. Può essere determinata in
modo univoco, con un numero, o parzialmente
determinato, con intervalli (es. 0..5) o espressioni
contenenti * (es. 1..*)
2010
Operazioni di una Classe
‫ ּס‬Le operazioni sono specificate da espression testuali nella
forma:
Visibilità Nome ( Lista Parametri ) : Tipo Risultato
dove per Visibilità valgono le regole esposte in precedenza
‫ ּס‬Un parametro in Lista Parametri può a sua volta essere
nella forma:
Tipo Nome : DataType = Valore iniziale
dove Tipo può essere in, out, o inout (NB: si noti l’analogia
con IEC 61131-3

2010
Interfacce
‫ ּס‬Gli attributi e le operazioni pubbliche costituiscono le

interfacce tra una classe e il resto del sistema.

2010
Interazioni tra le classi
‫ ּס‬Associazione, ricollegabile ad una relazione run-time

fra i relativi oggetti istanza; a loro volta qualificata
come:
– semplice
– di aggregazione
– di composizione
Un’associazione può essere ulteriormente dettagliata con
etichette testuali, direzionalità e molteplicità (ad entrambi
i capi della linea).
‫ ּס‬Generalizzazione, che specificano legami tra classi
base e classi derivate.
2010
Interazioni fra classi
‫ ּס‬Associazione semplice: gli oggetti di due classi legate
da tale relazione comunicano tra loro (scambio di
messaggi, richieste di operazioni).
‫ ּס‬Il numero di oggetti di ciascun tipo che possono essere
coinvolti dipende dalla molteplicità (es. 0..1, 1, 0..*, 1..*,
etc…)

2010
‫ ּס‬Associazione di Aggregazione: una classe “contiene”
l’altra. Se viene istanziata l’una, occorrono anche un
certo numero di istanze dell’altra (dipendente dalla
molteplicità dell’aggregazione).
1
1
1

2010
‫ ּס‬Associazione di Composizione (o Aggregazione Forte):
una una classe “contiene” l’altra ed è responsabile della
creazione delle istanze di quest’ultima, le quali non sono
condivisibili.
1
1
1
1
1
1 1
1

2010
Generalizzazione
‫ ּס‬Generalizzazione: una classe più generica è la base
per specializzarne il comportamento, definendo una
classe derivata che ne eredita le caratteristiche,
estendendole o ridefinendole.

2010
Descrizione di una macchina
‫ ּס‬Nel campo della automazione spesso il concetto di

classe coincide con il concetto di oggetto (è difficile
istanziare un oggetto hardware…)
‫ ּס‬Il diagramma delle classi descrive la struttura statica
della macchina, la sua suddivisione in moduli e come
questi moduli comunicano fra di loro.

2010
Un esempio: Tetra Pak filling machine
High Speed
High Flex
Asep.& Fill.
Main
El. Cab. High
Flex
Chemicals
ASU
ASU--m Forming FFU High
Unit Speed
Portion
High
Speed
High Flex High High Family
Speed Speed
Portion Family
2010
<<Specialized Module>>
High Speed Family forming unit
<<Module>>
<<Physical unit>> Forming Unit
Main Electrical Cabin
High speed portion flexible unit
<<Module>>
Automatic Splicing <<Specialized Module>>
Unit Flexible forming unit
<<Machine supervisor>>
Filling Machine
High Speed Family final
<<Module>> folder unit
Chemical Unit
<<Module>> <<Module>> High speed portion final folder
Aseptic unit Final Folder Unit unit
Flexible final folder unit
<<Specialized Module>> <<Specialized Module>>

Flexible aseptic unit High speed aseptic unit

2010
Altri concetti…
‫ ּס‬Interface: un’interfaccia è una particolare tipologia di

classe che contiene solo dichiarazioni (non definizioni) di
operazioni pubbliche (non ha stato né comportamento).
‫ ּס‬Package: è un generico “contenitore” per un gruppo di
elementi (di qualsiasi tipo) del modello correlati tra loro.
‫ ּס‬Classi attive: sono classi le cui istanze devono avere a
run-time il proprio spazio di esecuzione separato
(processo o thread).

2010
Interface
‫ ּס‬E’ definita come una serie di operazioni che
caratterizzano il comportamento dell’elemento.
‫ ּס‬Specifica in sostanza quali “servizi standard” possono
essere richiesti ad una classe senza specificare la
struttura interna (astrazione)
‫ ּס‬Una classe compatibile con una data interfaccia si dice
che la realizza. Realizzazione

2010
Package
‫ ּס‬Il package è un elemento di organizzazione del
modello
‫ ּס‬Ogni elemento del modello deve appartenere ad uno ed
un solo package (se non specificato è quello “default”)
‫ ּס‬Un package ne può contenere altri, oppure avere
relazioni del tipo “dipende da” con altri package: ad
esempio, una classe di un package utilizza una classe di
un altro package
‫ ּס‬Il package viene utilizzato per definire una unità
omogenea (ad esempio un modulo macchina ben
definito).

2010
Package (cont.)
UserInterface
Window ClientArea Monitoring
Scrollbar Sensor
TempSensor ProximitySensor
SDIWindow MDIWindow
DeviceIO MotorControl
SimpleDevice * Motor
Register
ADConverter StepperMotor
UART DualPortedRAM ContinuousMotor

2010
Estensione del linguaggio:
stereotipi
‫ ּס‬Al fine di permettere l’adattamento del linguaggio ai
concetti di un particolare contesto applicativo, UML
ammette un meccanismo di estensione basato sulla
definizione di nuove meta-classi, derivate da quelle
standard, chiamate stereotipi.
‫ ּס‬Gli stereotipi permettono l’estensione del vocabolario
di UML attraverso l’introduzione di nuovi simboli.
‫ ּס‬Ad uno stereotipo possono essere associati:
– proprietà aggiuntive, chiamate “Tagged Values”
– regole di utilizzo, identificate da vincoli formali
espressi nel linguaggio testuale OCL (Object
Constraint Language).

2010
Dichiarazione di uno
stereotipo

2010
Uso dello stereotipo

2010
Utilizzo degli stereotipi
‫ ּס‬Un insieme di stereotipi relativi ad un determinato contesto
applicativo viene chiamato profilo
‫ ּס‬Alcuni esempi di profili di dominio pubblico, sviluppati da
esperti di Ingegneria del Software, sono quelli per Business
Modeling, Web Modeling e per sistemi Real-Time (v.
seguito)
‫ ּס‬Nonostante la definizione di uno stereotipo si possa
applicare a qualsiasi concetto di UML, la pratica più
comune è quella di definire stereotipi della meta-classe
classe
‫ ּס‬Uno stereotipo di classe si può identificare precedendo il
nome della classe con <<Nome Stereotipo>> o con
un’icona (user-defined).

2010
Descrizione del comportamento
reattivo di un sistema in UML
Descrizione del
comportamento in UML
‫ ּס‬Che cosa si intende per Comportamento?
‫ ּס‬Il comportamento è l’evoluzione nel tempo del sistema o di
una sua parte (oggetto o insieme di oggetti):
– in risposta ad eventi (stimoli) esterni (al sistema o
all’oggetto) o generati internamente
– visibile all’esterno oppure non visibile all’esterno
‫ ּס‬A cosa si può associare la descrizione di un
comportamento?
– ad un Caso d’Uso
– ad un Sistema o un Sotto-sistema
– ad una Classe
– ad un insieme di oggetti

2010
Come descrivere il
comportamento con UML?
‫ ּס‬Diagrammi di interazione: se il comportamento da

descrivere è quello di un insieme di elementi che
collaborano.
‫ ּס‬Diagrammi di stato o di attività: se il comportamento da
descrivere è quello individuale di un elemento del
modello

2010
Concetti comuni nei
diagrammi d’interazione
‫ ּס‬Interazione: un insieme di comunicazioni scambiate tra

un gruppo di istanze, qualsiasi sia la modalità di
comunicazione:
– invocazione di operazioni
– attivazione di segnali
– creazione e distruzione di altre istanze
‫ ּס‬è sempre possibile stabilire un ordine temporale
(eventualmente parziale) tra le comunicazioni

2010
Tipologia delle comunicazioni
‫ ּס‬In ogni comunicazione c’è sempre un Mittente (sender )

e un Destinatario (receiver )
‫ ּס‬Le comunicazioni possono distinguersi in:
– Sincrone: il mittente attende che il destinatario abbia
“processato” la comunicazione (es. esecuzione
dell’operazione richiesta) per proseguire la propria
attività
– Asincrone: il mittente prosegue la propria attività
dopo aver “spedito” la comunicazione
‫ ּס‬Ovviamente, le comunicazioni asincrone presuppongono
che le istanze coinvolte siano relative a classi attive
2010
Terminologia
‫ ּס‬Chiamata (Call): specifica dell’attivazione di una

comunicazione sincrona.
‫ ּס‬Operazione: servizio fornito dal destinatario che
permette al mittente di effettuare la comunicazione
sincrona
‫ ּס‬Segnale: specifica dell’attivazione di una comunicazione
asincrona
‫ ּס‬Evento: verificarsi ad un dato istante di tempo di una
occorrenza rilevante per il destinatario (sia una chiamata
di operazione o l’attivazione di un segnale)

2010
Automation
Robotics and
System
Definiscono viste dinamiche del modello
DIAGRAMMI D’INTERAZIONE:
SEQUENCE E
COLLABORATION DIAGRAM.
2010
Diagrammi d’interazione: Sequence e
Collaboration Diagrams
‫ ּס‬Collaboration Diagrams: descrivono l’interazione tra

oggetti mediante stimoli (segnali) indicando un numero
d’ordine che si riferisce alla sequenza temporale.
‫ ּס‬Sequence Diagrams: stessi concetti, ma ad ogni
oggetto è assegnata una linea temporale (“lifeline”) che
scorre dall’alto verso il basso.

2010
Collaboration Diagram

2010
Collaboration Diagram
Oggetti
Link Messaggio

2010
Messaggi/Stimoli
‫ ּס‬Un Messaggio (o Stimolo) rappresenta l’entità

costitutiva di un interazione fra oggetti ed è specificato
da:
– un mittente
– un destinatario
– un contenuto informativo
‫ ּס‬Il contenuto informativo può essere:
– Una chiamata di un’operazione (function call)
– L’attivazione di un segnale (flag variable).
– La creazione o distruzione di un istanza
– Descritto informalmente con una nota testuale (in
fase di analisi)

2010
Notazioni per i messaggi
‫ ּס‬In UML standard, l’aspetto della freccia associata ad un

messaggio può essere
► per messaggi sincroni, o semplici (il sender attende il
termine dell’operazione invocata).
> per messaggi asincroni (il sender non attende il
termine dell’operazione invocata).
‫ ּס‬Altri simboli possono essere adottati dai tools grafici per
indicare, ad esempio, messaggi con acknowledge,
messaggi con timeout, messaggi periodici, etc.

2010
Oggetti “attivi”
‫ ּס‬Si noti che il concetto di Messaggio in UML estende quello
“primario” di invocazione metodi dei linguaggi di
programmazione OO
‫ ּס‬La possibilità di associare ad uno Stimolo l’attivazione di
un “segnale” (evento) e di aver comunicazioni “asincrone”,
rende i Collaboration Diagrams idonei a descrivere anche
le interazioni in sistemi Real-Time e multi-tasking.
‫ ּס‬Infatti, i Collaboration Diagrams prevedono una notazione
specifica (bordo più spesso) per Oggetti Attivi, cioè
oggetti che hanno un proprio “spazio di esecuzione”
(processo o thread).

2010
Note sui Collaboration
Diagram
‫ ּס‬Sostanzialmente, i Collaboration Diagrams “estendono”
l’aspetto di un Object Diagram con specifiche
“dinamiche” (i messaggi).
‫ ּס‬Tuttavia, la reale sequenza degli eventi non è
immediatamente comprensibile.
‫ ּס‬In caso di modifiche o perfezionamento (tipico in un
processo di sviluppo iterativo) può essere difficile
mantenere coerente la numerazione dei messaggi.
‫ ּס‬Soluzione: diagrammi che evidenziano la “linea
temporale”: sequence diagram.

2010
Sequence diagram

2010
Sequence diagram
Oggetti
“Send” stimolo
“Return” stimolo
“Focus of control”
dell’oggetto

2010
Notazione dei Sequence
Diagrams
‫ ּס‬Attivazione (Focus of control): indica quando un’istanza è
“attiva”, cioè sta eseguendo un’operazione, direttamente o
indirettamente (in attesa del risultato da un’altra istanza).
– rappresentato graficamente con un rettangolo allungato
sulla lifeline dell’istanza
‫ ּס‬Ritorno: termine dell’esecuzione di un’operazione (per
comunicazioni sincrone), rappresentata con una freccia
tratteggiata
‫ ּס‬Precondizioni: condizioni booleane racchiusa da parentesi
quadre che precedono il nome del messaggio, devono essere
verificate per l’effettivo invio della comunicazione
‫ ּס‬Biforcazioni condizionali: allo stesso istante si possono
generare messaggi diversi, alternativi, con precondizioni
diverse

2010
Ordinamento temporale degli
eventi
‫ ּס‬Per ogni messaggio si identificano due eventi temporali,
invio e ricezione, identificati con la notazione Nome
msg.sendTime e Nome msg.receiveTime
‫ ּס‬Formalmente, tali eventi sono solo parzialmente
ordinati, poichè si assume che gli oggetti in un
Sequence Diagram siano potenzialmente concorrenti
(lifeline non allineate temporalmente)
‫ ּס‬Le regole di ordinamento parziale sono:
1. eventi sulla stessa lifeline (send o receive) sono
totalmente ordinati
2. Nome msg.sendTime precede sempre Nome
msg.receiveTime
3. l’ordine di tutti gli altri eventi non `e determinato
2010
Specifiche Real-Time e
Sequence Diagrams
‫ ּס‬In un sistema Real-Time e multitasking, le comunicazioni

fra oggetti sono in larga misura asincrone (oggetti
“attivi”).
‫ ּס‬In tali casi, le regole di ordinamento parziale descritte in
precedenza possono non essere sufficienti per le
specifiche di analisi e di progetto.
‫ ּס‬I Sequence Diagrams possono essere arricchiti con
vincoli temporali più dettagliati.

2010
Utilizzo dei Sequence
Diagrams
‫ ּס‬Un Sequence Diagram rappresenta un possibile
scenario (in genere non tutti quelli possibili)
‫ ּס‬Pertanto può essere utilizzato per:
– la descrizione di un Caso d’Uso: in questo caso, le
istanze presenti saranno gli attori e il sistema da
progettare (requisiti temporali)
– la descrizione di una dinamica interna al sistema,
corrispondente ad una sequenza osservabile in fase
di debug (template per test di verifica)
‫ ּס‬D’altra parte, un Caso d’Uso è realizzato attraverso una
collaborazione di oggetti del sistema
– il Sequence Diagram del Caso d’Uso può essere
esteso per ottenere un Sequence Diagram di progetto

2010
Diagrammi UML orientati allo
stato
‫ ּס‬State Diagrams: derivati dalla notazione degli

Statecharts di Harel, estensione dei diagrammi di stato
tradizionali.
‫ ּס‬Activity Diagrams: descrizione “ibrida” tra diagrammi di
stato e flow-chart tradizionali, può descrivere anche
specifiche “collaborative” (attività di più oggetti sullo
stesso diagramma)

2010
UML State Diagrams
‫ ּס‬Nel meta-modello UML, ad alcuni elementi (Classi, Casi

d’Uso, etc.) può essere associata una Macchina a Stati
(State Machine o Finite State Machine, FSM), che ne
specifica in modo completo il comportamento
‫ ּס‬Formalmente, la Macchina a Stati è costituita da:
– un insieme S, finito ed enumerabile, di stati
– un insieme T di transizioni, ognuna delle quali
collega un elemento di S (sorgente) con un altro
elemento di S (destinazione)
– un insieme E di eventi rilevabili dalla Macchina a
Stati
– un insieme A di azioni eseguibili dalla Macchina a
Stati

2010
Definizioni
‫ ּס‬Uno stato è una condizione fondamentale nell’esistenza di
un entità che persiste per un periodo di tempo significativo
ed è distinguibile da ogni altra condizione.
‫ ּס‬Una condizione esistenziale si dice distinguibile da ogni
altra se differisce:
– Negli eventi (stimoli) che possono essere accettati
– Nelle transizioni che possono modificare tale
condizione, attivandone un’altra
– Nelle azioni che vengono eseguite
‫ ּס‬Una transizione è la risposta ad uno stimolo di interesse
(rilevabile nello stato attuale) che causa un cambiamento
nello stato
2010
Esempi
‫ ּס‬Un interruttore può essere {ACCESO, SPENTO}

‫ ּס‬Un ascensore può essere {FERMO CON PORTE
CHIUSE, FERMO CON PORTE APERTE, IN SALITA, IN
DISCESA}
‫ ּס‬Un dispositivo di misura può essere {SPENTO, IN
CALIBRAZIONE, MISURA CORRETTAMENTE,
MISURA ERRONEAMENTE}
– NOTA: un oggetto software per la comunicazione con
il dispositivo avrà verosimilmente un attributo che
memorizza il valore misurato, ma un insieme di stati
{0, 0.01, 0.02, ... 10 V} non è disgiunto in valori
significativamente distinguibili (dal punto di vista
comportamentale)

2010
Diagramma diStato
stato
inizialeper l’ascensore
(default)
Stati
Transizioni

2010
Diagramma di stato con azioni e
attivita’
Attivita’
Azioni

2010
Definizioni: azioni e attività
‫ ּס‬Una azione è una specifica di un comportamento
(operazione, assegnamento a variabili, etc.) non
interrompibile e di durata temporale limitata (al limite
infinitesima).
‫ ּס‬Una attività è una specifica di comportamento di durata
significativa, interrompibile in reazione ad eventi esterni.
‫ ּס‬L’esecuzione di un’azione, che è da considerarsi
istantanea, può essere associata a:
– una transizione
– l’istante di attivazione di uno stato
– l’istante di disattivazione di uno stato
‫ ּס‬L’esecuzione di un’attività è associata ad uno stato
(eseguita fintanto che lo stato è attivo)
2010
Limitazione dei diagrammi di
stato tradizionali (SFC)
‫( ּס‬1) Scalabilita’: alcuni stati debbono essere raggiunti da
tutti gli altri stati.
State1 State2
State5
State3 State4

2010
Statechart: Gerarchia di stati (OR-
States).
Superstate
State1 State2
State5
State3 State4

2010
Macrostati per la gestione delle
eccezioni
Supertati, Macrostati
2010
Limitazione dei diagrammi di
stato tradizionali (SFC)
‫( ּס‬2) Distinguibilita’: in alcuni casi, uno stato non può
essere decomposto in una singola sotto-sequenza
‫ ּס‬Esempio: un dispositivo può essere:
{SPENTO, ACCESO}, ma quando ACCESO può essere
sia {IN ATTESA, OPERATIVO, BLOCCATO} che {CON
DISPLAY ACCESO, CON DISPLAY SPENTO}

2010
Statechart: Gerarchia di stati
concorrenti (AND -States).
Superstate1
SuperstateA SuperstateB
State3
State1
State4
State2
State5

2010
Evoluzione dei diagrammi di
stato: Statecharts
‫ ּס‬Formalizzato da David Harel nel 1987, il linguaggio degli
Statecharts ha le caratteristiche per descrivere Macchine
a Stati molto complesse in una forma graficamente
compatta:
– Gerarchia di stati innestati (OR-states)
– Concorrenza fra stati (AND-states)
– Transizioni inter-livello (no limitazioni legate
all’innestamento)
– Macro-stati con memoria
– Punti di sincronizzazione fra sotto-stati concorrenti
– Punti di scelta fra transizioni
‫ ּס‬Sfruttato per gli editor di diversi tools di simulazione (es.
Matlab/Stateflow)
‫ ּס‬Adottato pienamente dallo standard UML
2010
Sintassi dello Statechart
‫ ּס‬Pseudostati iniziale e finale

2010
‫ ּס‬Azioni e attività

2010
guard: espressione booleana di
‫ ּס‬Transizioni “guardia”
trigger: evento effect: azione effettuata

scatenante la transizione in corrispondenza della
transizione

2010
‫ ּס‬Self-transition

2010
Differenza fra “internal
transition” e “self transition”
StateX
entry / Action1 eventZZ / Action3
exit / Action2
eventYY / Action3
‫ ּס‬Se si verifica eventYY, esegue Action3 (“Internal

Transition”)
‫ ּס‬Se si verifica eventZZ, esegue Action2, poi Action3, poi
Action1 (esce e rientra in StateX, “Self Transition”)

2010
Espressioni testuali negli stati
‫ ּס‬Azioni all’attivazione: entry / Azioni

‫ ּס‬Azioni alla disattivazione: exit / Azioni
‫ ּס‬Attività durevoli: do / Attività
‫ ּס‬Reazioni:
Evento(Parametri) [Condizione] / Azioni
servono per reagire a certi eventi senza cambiare di
stato (chiamate anche Internal Transitions)

2010
Espressioni testuali su
transizioni
‫ ּס‬In generale, ad una transizione si può associare un’espressione del
tipo:
Evento(Parametri) [Condizione] ^ Eventi gen / Azioni
dove:
– Evento è lo stimolo che “scatena” (trigger) la transizione
– Condizione è un espressione booleana (guard), che deve
essere vera all’istante dell’evento “trigger”, altrimenti la
transizione non viene effettuata
– Eventi gen sono eventi “generati” dalla Macchina a Stati, verso
altri oggetti o verso regioni concorrenti della stessa Macchina a
Stati
– Azioni sono, come detto, operazioni o semplici assegnamenti
da compiere all’atto dell’esecuzione della transizione

2010
Terminologia per gli eventi
‫ ּס‬Call Event: chiamata esplicita di un’operazione (v.

comunicazione sincrona)
‫ ּס‬Signal Event: attivazione di un segnale (v.
comunicazione asincrona)
‫ ּס‬Time Event: termine di un determinato periodo di
tempo, iniziato a partire da un altro evento o
dall’ingresso in uno stato (notazione: tm(Valore durata))
‫ ּס‬Change Event: passaggio da falso a vero di una
espressione booleana

2010
Sommario: Sintassi base degli
Statecharts

2010
Sintassi estesa degli
Statechars: pseudostati
‫ ּס‬History, indicato con una H cerchiata, all’interno di un
macro-stato: la transizione che ha tale pseudostato come
destinazione sarà “rediretta” verso l’ultimo stato attivo prima
della disattivazione del macro-stato (se indicato con H* la
memoria arriva fino al più basso livello della gerarchia).
‫ ּס‬Choice, indicato con una C cerchiata, per transizioni
composte e condizionate: il tratto che entra deve avere solo
il “trigger”, i tratti uscenti delle “guard” mutuamente
esclusive
‫ ּס‬Fork/Join, per specificare quali sotto-stati concorrenti di un
AND-state attivare/disattivare
‫ ּס‬Synch, per definire un punto d’incontro fra sotto-sequenze
di stati concorrenti

2010
Esempio con History
Superstate
State5
State1 State2
State3 State4 H State6

2010
Esempio con Choice
Superstate
State1
State2
[Cond2]
[Cond1]
[Cond3]
C
State3
ev1
State4
2010
Esempio con Fork/Join

2010
Esempio con Synch

2010
Riassumendo...

2010

05 Uml

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

05 Uml

Caricato da

Copyright:

Formati disponibili

Automation

Cesare Fantuzzi (cesare.fantuzzi@unimore.it)

Nota: il materiale didattico è adattato dal materiale sviluppato in

Settembre - Dicembre Automazione Industriale - 5. UML 4

Settembre - Dicembre Automazione Industriale - 5. UML 5

Settembre - Dicembre Automazione Industriale - 5. UML 6

Settembre - Dicembre Automazione Industriale - 5. UML 7

‫ ּס‬La specifica OMG definisce UML come:

“The Unified Modeling Language (UML) is a graphical

Settembre - Dicembre Automazione Industriale - 5. UML 8

‫ ּס‬Lo UML non è un linguaggio di programmazione

Settembre - Dicembre Automazione Industriale - 5. UML 9

‫ ּס‬Linguaggio interamente visuale (basato su una sintassi

Settembre - Dicembre Automazione Industriale - 5. UML 10

Settembre - Dicembre Automazione Industriale - 5. UML 11

‫ ּס‬Descrizione requisiti: (1) Use Case Diagrams

Settembre - Dicembre Automazione Industriale - 5. UML 12

Un caso d’uso (USE CASE) rappresenta una funzionalità completa

USE CASE DIAGRAMS

Settembre - Dicembre Automazione Industriale - 5. UML 13

Settembre - Dicembre Automazione Industriale - 5. UML 14

Settembre - Dicembre Automazione Industriale - 5. UML 15

Settembre - Dicembre Automazione Industriale - 5. UML 16

Settembre - Dicembre Automazione Industriale - 5. UML 17

Settembre - Dicembre Automazione Industriale - 5. UML 18

Settembre - Dicembre Automazione Industriale - 5. UML 19

‫ ּס‬Generalizzazione/Specializzazione: questa relazione è

Settembre - Dicembre Automazione Industriale - 5. UML 20

‫ ּס‬Graficamente, la generalizzazione è raffigurata da

Settembre - Dicembre 2010 Automazione Industriale - 21

‫ ּס‬Gli Use Case Diagrams prevedono sempre un sistema e

Settembre - Dicembre Automazione Industriale - 5. UML 22

Azionista Acquista Acquirente

Settembre - Dicembre Automazione Industriale - 5. UML 24

Settembre - Dicembre Automazione Industriale - 5. UML 27

Settembre - Dicembre Automazione Industriale - 5. UML 28

Il Diagramma delle Classi descrive la struttura statica del sistema.

Settembre - Dicembre Automazione Industriale - 5. UML 30

‫ ּס‬Aristotele: Tutti gli esseri viventi (oggetti) sebbene unici,

Settembre - Dicembre Automazione Industriale - 5. UML 31

‫ ּס‬La relazione tra

Settembre - Dicembre Automazione Industriale - 5. UML 32

‫ ּס‬Un oggetto possiede

Settembre - Dicembre Automazione Industriale - 5. UML 33

Settembre - Dicembre Automazione Industriale - 5. UML 34

Class Name Object Name : Class

Settembre - Dicembre Automazione Industriale - 5. UML 35

dove Visibilità può essere indicata con il nome o con un

Settembre - Dicembre Automazione Industriale - 5. UML 37

‫ ּס‬Gli attributi e le operazioni pubbliche costituiscono le

Settembre - Dicembre Automazione Industriale - 5. UML 38

‫ ּס‬Associazione, ricollegabile ad una relazione run-time

Settembre - Dicembre Automazione Industriale - 5. UML 40

Settembre - Dicembre Automazione Industriale - 5. UML 41

Settembre - Dicembre Automazione Industriale - 5. UML 42

Settembre - Dicembre Automazione Industriale - 5. UML 43

‫ ּס‬Nel campo della automazione spesso il concetto di

Settembre - Dicembre Automazione Industriale - 5. UML 44

<<Specialized Module>> <<Specialized Module>>

Settembre - Dicembre Automazione Industriale - 5. UML 46

‫ ּס‬Interface: un’interfaccia è una particolare tipologia di

Settembre - Dicembre Automazione Industriale - 5. UML 47

Settembre - Dicembre Automazione Industriale - 5. UML 48