5. Unified Modeling Language

(1)

Università degli Studi di Modena e Reggio Emilia Automation

Robotics and System CONTROL

Automazione Industriale

5 - Il linguaggio descrittivo UML

Cesare Fantuzzi (cesare.fantuzzi@unimore.it)

Ingegneria Meccatronica

Ingegneria della Gestione Industriale AA 2010/2011

(2)

Università degli Studi di Modena e Reggio Emilia Automation Robotics and System CONTROL

UNIFIED MODELING

LANGUAGE

Nota: il materiale didattico è adattato dal materiale sviluppato in

collaborazione con Marcello Bonfè (marcello.bonfe@unife.it),

(3)

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,

(4)

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.

(5)

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.

(6)

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.

(7)

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.

nascere l’esigenza di una standardizzazione.

סּ Standard: Unified Modeling Language pubb.da OMG (Object Management Group).

(8)

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,

(9)

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.

(10)

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. – Requisiti funzionali => Requirement Capture.

– Classificazione e relazioni tra gli oggetti => Object structure.

(11)

(12)

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) סּ Comportamento di interazione: (4)Collaboration, (5)

Sequence and (6) Activity diag.

סּ Architettura implementativa: (7) Component and (8)

(13)

USE CASE DIAGRAMS

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

(14)

(15)

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

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

(16)

Elementi degli Use Case

diag.

(17)

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

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

(18)

Elementi del diagramma:

(19)

Elementi del diagramma:

Inclusione

(20)

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 סּ Inclusione (Include): è una relazione del tipo

client/server fra casi d’uso, cioè una funzionalità comune viene “sfruttata” per realizzare altri casi d’uso.

(21)

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>>:

(22)

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

(23)

Un esempio: un sistema

Azienda

Azionista Sistema azienda Acquirente Distribuisci dividendi Acquista merci Azionista Stato Fornitore merci Paga tasse Acquista materie prime

(24)

Un esempio: un sistema Azienda

(cont.)

(25)

Un esempio: un sistema

Azienda (cont.)

Sistema produzione Sistema vendite Acquirente produzione Sistema amministrazione

(26)

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

(27)

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

3. Chiudi pinza

4. Sali in posizione di volo

סּ Postcondizione: Braccio collocato sul pezzo, pezzo afferrato.

(28)

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.

prima che sia eseguito il caso d’uso.

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

(29)

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

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

(30)

CLASS DIAGRAMS

(31)

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

(32)

Relazione tra oggetti e classi

סּ La relazione tra

Classe e Oggetto è

analoga a quella tra

(33)

Elementi fondamentali di un

oggetto.

סּ Un oggetto possiede – Uno stato – Un comportamento – Una identità

סּ La struttura e il comportamento di oggetti simili sono סּ La struttura e il comportamento di oggetti simili sono

definiti nella loro classe comune; i termini di istanza e oggetto sono intercambiabili [Grady Booch]

(34)

(35)

Classe e oggetto

Class Name Object Name : Class

Attribute type = 'Value'

Nome della classe

Attributi (dati) Metodo (operazione)

attribute:Type =initialValue operation(arg list):return type

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

(36)

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

(37)

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: nella forma:

Tipo Nome : DataType = Valore iniziale

dove Tipo può essere in, out, o inout (NB: si noti l’analogia con IEC 61131-3

(38)

Interfacce

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

(39)

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.

(40)

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

(41)

Interazioni fra classi

סּ 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

(42)

Interazioni fra classi

סּ 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 1

(43)

Generalizzazione

סּ Generalizzazione: una classe più generica è la base per specializzarne il comportamento, definendo una classe derivata che ne eredita le caratteristiche,

(44)

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 della macchina, la sua suddivisione in moduli e come questi moduli comunicano fra di loro.

(45)

Un esempio: Tetra Pak filling machine High High Flex Flex H ig h F le x H ig h F le x Main Main El. Cab. El. Cab. Asep.& Fill. Asep.& Fill. H ig h S p e e d H ig h S p e e d High High High High Speed Speed Family Family High Flex High Flex Flex Flex ASU

ASU--mm Forming Forming Unit Unit FFU FFU C h e m ic a ls C h e m ic a ls High High High High Speed Speed Portion Portion

(46)

<<Machine supervisor>> Filling Machine

<<Specialized Module>> High Speed Family final folder 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 Splicing Unit

<<Specialized Module>> High speed portion final folder unit

<<Specialized Module>> High speed aseptic unit <<Specialized Module>>

Flexible aseptic unit

<<Module>> Aseptic unit

<<Module>> Final Folder Unit

<<Specialized Module>> Flexible final folder unit

(47)

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

(48)

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}

(49)

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

(50)

Package (cont.)

UserInterface SDIWindow MDIWindow Scrollbar ClientArea _Monitoring TempSensor Sensor ProximitySensor Window MotorControl ContinuousMotor Motor StepperMotor DeviceIO Register DualPortedRAM ADConverter SimpleDevice UART *

(51)

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

(52)

Dichiarazione di uno

stereotipo

(53)

(54)

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 סּ 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

(55)

Descrizione del comportamento

reattivo di un sistema in UML

(56)

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

– 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

(57)

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

descrivere è quello individuale di un elemento del modello

(58)

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

(59)

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

“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

(60)

Terminologia

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

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

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)

(61)

Università degli Studi di Modena e Reggio Emilia Automation Robotics and System CONTROL

DIAGRAMMI D’INTERAZIONE:

SEQUENCE E

COLLABORATION DIAGRAM.

(62)

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 oggetto è assegnata una linea temporale (“lifeline”) che scorre dall’alto verso il basso.

(63)

(64)

Collaboration Diagram

Oggetti

(65)

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)

(66)

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

termine dell’operazione invocata).

סּ Altri simboli possono essere adottati dai tools grafici per indicare, ad esempio, messaggi con acknowledge,

(67)

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.

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

(68)

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 סּ 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

(69)

(70)

Sequence diagram

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

(71)

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

(72)

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)

(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

(73)

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

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

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

(74)

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

(75)

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

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

(76)

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

(77)

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

(78)

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,

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)

(79)

Diagramma di stato per l’ascensore

Stati

Stato iniziale (default)

(80)

Diagramma di stato con azioni e

attivita’

Attivita’

(81)

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

סּ 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)

(82)

Limitazione dei diagrammi di

stato tradizionali (SFC)

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

State1 State2

State3 State4

(83)

Statechart: Gerarchia di stati

(OR-States).

Superstate State1 State2 State5 State3 State4

(84)

Macrostati per la gestione delle

eccezioni

(85)

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}

(86)

Statechart: Gerarchia di stati

concorrenti (AND -States).

Superstate1 State1 State3 SuperstateA SuperstateB State2 State4 State5

(87)

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

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

(88)

Sintassi dello Statechart

(89)

Sintassi dello Statechart

(90)

Sintassi dello Statechart

סּ Transizioni guard: espressione booleana di _{“guardia”}

trigger: evento

scatenante la transizione

effect: azione effettuata in corrispondenza della

(91)

Sintassi dello Statechart

(92)

Differenza fra “internal

transition” e “self transition”

StateX

entry / Action1 exit / Action2

eventYY / Action3

eventZZ / 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”)

(93)

Espressioni testuali negli stati

סּ Azioni all’attivazione: entry / Azioni סּ Azioni alla disattivazione: exit / Azioni סּ Attività durevoli: do / Attività

סּ Reazioni:

Evento(Parametri) [Condizione] / Azioni Evento(Parametri) [Condizione] / Azioni

servono per reagire a certi eventi senza cambiare di stato (chiamate anche Internal Transitions)

(94)

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

(95)

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

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

(96)

Sommario: Sintassi base degli

Statecharts

(97)

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

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

(98)

Esempio con History

Superstate

State1 _State2 State5

State3 State4

State6

(99)

Esempio con Choice

Superstate State1 State2 [Cond2] State3 C ev1 [Cond1] [Cond3]

(100)

(101)

(102)