automazione industriale 5 - il linguaggio descrittivo uml · settembre - dicembre 2 2010...

Università degli Studidi Modena e Reggio Emilia

AutomationRobotics and

SystemCONTROL

Automazione Industriale5 - Il linguaggio descrittivo UML

Cesare Fantuzzi ([email protected])

Ingegneria MeccatronicaIngegneria della Gestione Industriale

AA 2010/2011



SystemCONTROL

UNIFIED MODELINGLANGUAGE

Nota: il materiale didattico è adattato dal materiale sviluppato in collaborazione con Marcello Bonfè ([email protected]), dell’Università di Ferrara.

2Settembre - Dicembre 2010

Automazione Industriale - 5. UML

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 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.)

Settembre - Dicembre 2010

Automazione Industriale - 5. UML 3

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


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.

4Automazione Industriale - 5. UML

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 facilitare le comunicazioni fra il team di progetto.� Per sviluppare un piano di test e validazione.� Per documentare il progetto.


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.


Un linguaggio per la progettazione OO: UML

� Tra gli anni 70’ e 90’ sono state proposti molti metodi dianalisi 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 .


nascere l’esigenza di una standardizzazione .� Standard: Unified Modeling Language pubb.da OMG

(Object Management Group).

http://www.uml.org/


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. 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."


Automazione Industriale - 5. UML 8

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.


9

software.


UML (Unified ModelingLanguage)

� 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.


10

– Requisiti funzionali => Requirement Capture.– Classificazione e relazioni tra gli oggetti => Object

structure.– Comportamento degli oggetti => Object behaviour


I diagrammi dello UML



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)


12

� Comportamento di interazione: (4)Collaboration, (5) Sequence and (6) Activity diag.

� Architettura implementativa: (7) Component and (8) Deployment diag.




SystemCONTROL

USE CASE DIAGRAMS

Un caso d’uso (USE CASE) rappresenta una funzionalità completa così come viene percepita da un attore che interagisce con il sistema.



Use case diagram



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 ”.


15

“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 )


Elementi degli Use Case diag.



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


17

(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.


Elementi del diagramma: Generalizzazione/Specializzazione



Elementi del diagramma: Inclusione



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


20

� 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.


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 21Automazione Industriale -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


22

requisiti, identificare una scomposizione del sistemaglobale 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


Un esempio: un sistema Azienda

Azionista

Sistemaazienda

Acquirente

Distribuiscidividendi

Acquistamerci


23

Azionista

StatoFornitore

merci

Paga tasse

Acquista materieprime


Un esempio: un sistema Azienda (cont.)



Un esempio: un sistema Azienda (cont.)

Sistema produzione

Sistemavendite

Acquirente


25

produzione

Sistemaamministrazione


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.


26

– 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.


Flusso delle attività (esempio)

Caso d’uso: “Afferra pezzo grezzo”� Precondizione: Il braccio deve essere collocato sul pezzo.� Flusso di attività (passi):

1. Apri pinza2. Scendi sul pezzo3. Chiudi pinza


27

3. Chiudi pinza4. Sali in posizione di volo

� Postcondizione: Braccio collocato sul pezzo, pezzo afferrato.


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.


28

prima che sia eseguito il caso d’uso.– Le postcondizioni, cioè le condizioni del sistema dopo che è

eseguito il caso d’uso.


Il ruolo dei “casi d’uso” nellacattura 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


29

– 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)




SystemCONTROL

CLASS DIAGRAMSIl Diagramma delle Classi descrive la struttura statica del sistema.



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


31

– 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.


Relazione tra oggetti e classi

� La relazione tra Classe e Oggetto è analoga a quella tra Tipo e Variabile



Elementi fondamentali di un oggetto.

� Un oggetto possiede– Uno stato– Un comportamento– Una identità

� La struttura e il comportamento di oggetti simili sono


33

� La struttura e il comportamento di oggetti simili sono definiti nella loro classe comune; i termini di istanza e oggetto sono intercambiabili [Grady Booch]


Sintassi della classe



Classe e oggetto

Class Name Object Name : Class

Attribute type = 'Value'

Nome della classe

Attributi (dati)

Metodo (operazione)


35

attribute:Type =initialValue

operation(arg list):return type

Attribute type = 'Value'Attribute type = 'Value'Attribute type = 'Value'

Attribute type = 'Value'

Classe Oggetto


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


36

+ 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..*)


Operazioni di una Classe

� Le operazioni sono specificate da espression testuali nella forma:

Visibilità Nome ( Lista Parametri ) : Tipo Risultatodove per Visibilità valgono le regole esposte in precedenza� Un parametro in Lista Parametri può a sua volta essere

nella forma:


37

nella forma:Tipo Nome : DataType = Valore inizialedove Tipo può essere in, out, o inout (NB: si noti l’analogia

con IEC 61131-3


Interfacce

� Gli attributi e le operazioni pubbliche costituiscono le interfacce tra una classe e il resto del sistema.



Interazioni tra le classi

� Associazione , ricollegabile ad una relazione run-time fra i relativi oggetti istanza ; a loro volta qualificata come:– semplice– di aggregazione


39

– 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.


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…)




� 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


41

1

1



� 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


42

1

1

1

1

1

1

1


Generalizzazione

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



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 staticadella macchina, la sua suddivisione in moduli e come


44

della macchina, la sua suddivisione in moduli e come questi moduli comunicano fra di loro.


Un esempio: Tetra Pak filling machine

High High FlexFlex

High Flex

High Flex

MainMainEl. Cab.El. Cab.

Asep.& Fill.Asep.& Fill.

High Speed

High Speed


45

High High SpeedSpeedFamilyFamily

High High SpeedSpeedFamilyFamilyHigh FlexHigh Flex

FlexFlex

ASUASU--mm Forming Forming UnitUnit

FFUFFU

Chemicals

Chemicals

High High SpeedSpeedPortionPortion

High High SpeedSpeedPortionPortion


<<Machine supervisor>>Filling Machine

<<Specialized Module>>High Speed Family finalfolder unit

<<Specialized Module>>High Speed Family forming unit

<<Module>>Forming Unit

<<Module>>Chemical Unit

<<Specialized Module>>Flexible forming unit

<<Specialized Module>>High speed portion flexible unit

<<Physical unit>>Main Electrical Cabin

<<Module>>Automatic SplicingUnit


46

<<Specialized Module>>High speed portion final folderunit

<<Specialized Module>>High speed aseptic unit

<<Specialized Module>>Flexible aseptic unit

<<Module>>Aseptic unit

<<Module>>Final Folder Unit

<<Specialized Module>>Flexible final folder unit


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.


47

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).


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


48

che la realizza . Realizzazione


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


49

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).


Package (cont.)

UserInterface

SDIWindow MDIWindow

Scrollbar

ClientArea Monitoring

TempSensor

Sensor

ProximitySensor

Window


50

MotorControl

ContinuousMotor

Motor

StepperMotor

DeviceIO

Register

DualPortedRAM

ADConverter

SimpleDevice

UART

*


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 vocabolariodi UML attraverso l’introduzione di nuovi simboli.


51

� Gli stereotipi permettono l’estensione del vocabolariodi 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).


Dichiarazione di uno stereotipo



Uso dello stereotipo



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


54

� 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).


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


56

– 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


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


57

descrivere è quello individuale di un elemento del modello


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


58

– creazione e distruzione di altre istanze� è sempre possibile stabilire un ordine temporale

(eventualmente parziale) tra le comunicazioni


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


59

“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


Terminologia

� Chiamata (Call): specifica dell’attivazione di una comunicazione sincrona.

� Operazione: servizio fornito dal destinatario che permette al mittente di effettuare la comunicazione sincrona


60

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)




SystemCONTROL

DIAGRAMMI D’INTERAZIONE: SEQUENCE E COLLABORATION DIAGRAM.

Definiscono viste dinamiche del modello



Diagrammi d’interazione: Sequence eCollaboration 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


62

oggetto è assegnata una linea temporale (“lifeline”) che scorre dall’alto verso il basso.


Collaboration Diagram



Collaboration Diagram

Oggetti


64

Link Messaggio


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


65

– 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)


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).


66

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.


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.


67

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).


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


68

� 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 .


Sequence diagram



Sequence diagram

Oggetti


70

“Send” stimolo

“Return” stimolo“Focus of control”

dell’oggetto


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


71

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


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)


72

(lifeline non allineate temporalmente)� Le regole di ordinamento parziale sono:1. eventi sulla stessa lifeline (send o receive) sono

totalmente ordinati2. Nome msg.sendTime precede sempre Nome

msg.receiveTime3. l’ordine di tutti gli altri eventi non `e determinato


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


73

precedenza possono non essere sufficienti per le specifiche di analisi e di progetto.

� I Sequence Diagrams possono essere arricchiti con vincoli temporali più dettagliati.


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)


74

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


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


75

stato e flow-chart tradizionali, può descrivere anche specifiche “collaborative” (attività di più oggetti sullo stesso diagramma)


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


76

– 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


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


77

– 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


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,


78

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)


Diagramma di stato per l’ascensore

Stati

Stato iniziale (default)


79

Transizioni


Diagramma di stato con azioni e attivita’


80

Attivita’

Azioni


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


81

� 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)


Limitazione dei diagrammi di stato tradizionali (SFC)

� (1) Scalabilita’: alcuni stati debbono essere raggiunti da tutti gli altri stati.

State1 State2


82

State1 State2

State3 State4

State5


Statechart: Gerarchia di stati (OR-States).

Superstate

State1 State2

State5


83

State3 State4


Macrostati per la gestione delleeccezioni


84

Supertati, Macrostati


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}


85

DISPLAY ACCESO, CON DISPLAY SPENTO}


Statechart: Gerarchia di staticoncorrenti (AND -States).Superstate1

State1State3

SuperstateA SuperstateB


86

State2

State4

State5


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


87

– 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


Sintassi dello Statechart

� Pseudostati iniziale e finale




� Azioni e attività




� Transizioniguard: espressione booleana di

“guardia”


90

trigger: evento scatenante la transizione

effect: azione effettuata in corrispondenza della

transizione



� Self-transition



Differenza fra “internaltransition” e “self transition”

StateX

entry / Action1exit / Action2eventYY / Action3

eventZZ / Action3


92

� 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”)


Espressioni testuali negli stati

� Azioni all’attivazione : entry / Azioni� Azioni alla disattivazione : exit / Azioni� Attività durevoli : do / Attività� Reazioni : Evento(Parametri) [Condizione] / Azioni


93

Evento(Parametri) [Condizione] / Azioniservono per reagire a certi eventi senza cambiare di stato (chiamate anche Internal Transitions)


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


94

– 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


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


95

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


Sommario: Sintassi base degli Statecharts



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


97

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


Esempio con History

Superstate

State1 State2State5


98

State3 State4State6H


Esempio con ChoiceSuperstate

State1State2

[Cond2]


99

State3

C

State4

ev1

[Cond1]

[Cond3]


Esempio con Fork/Join



Esempio con Synch



Riassumendo...



automazione industriale 5 - il linguaggio descrittivo uml · settembre - dicembre 2 2010...

Documents