Transcript IEC614999

Dipartimento di
Informatica e Sistemistica
UML E NORME IEC
Alessandro DE CARLI
Anno Accademico 2006-07
In collaborazione con
Andrea Censi, Massimo Ferri e Luca Marchionni
Indice
1) Riflessioni sulle problematiche del software
nell’automazione.
2) La norma IEC 61499
3) Un semplice caso di studio con IEC 61499
4) Approccio object-oriented
5) Il linguaggio UML
6) Un semplice caso di studio (reprise)
7) Conclusioni
Il software nell’automazione (1/4)
GESTIONE
SUPERVISIONE
COORDINAMENTO
CAMPO
Quali sono le funzionalità
“informatiche” necessarie in
ambito industriale?
I fenomeni “dominanti”:
• Campo: elaborazione dati
• Coordinamento: trasmissione dati
• Supervisione: analisi e
visualizzazione dati
• Gestione: conservazione dati
Il software nell’automazione (2/4)
In tutte le aree applicative informatiche l’automazione non
ha bisogno di prestazioni estreme o funzionalità
avanzate. Per esempio:
• Elaborazione: per il controllo di un processo servono
moderate capacità di DSP (un processo “veloce” non
arriva a più di 2kHz).
– Un cellulare UMTS de/comprime audio e video in tempo reale.
• Trasmissione: la banda necessaria è proporzionale alle
velocità dei processi (kb/s). Non sono necessarie
tecnologie particolari di routing.
– Le reti a pacchetti moderne con QoS arrivano al gB/s.
Il software nell’automazione (3/4)
• Visualizzazione: non è sentita la necessità di avere
prestazioni/qualità avanzate.
– Un semplice videogioco fornisce visualizzazione 3D.
– Alcuni campi applicativi hanno bisogno di precisi studi di HCI
(human-computer interface) o HRI (human-robot interface).
• Conservazione dati:
– Telecom dagli anni 60 gestisce DB da milioni di utenti
– il sistema di prenotazione mondiale per le linee aeree fornisce
un DB consistente a migliaia di punti vendita.
Il software nell’automazione (4/4)
Alcuni requisiti specifici per il software nell’automazione:
• il tempo di vita del software è più lungo essendo legato a
quello dell’impianto
 documentabilità e manutenibilità delle soluzioni
• le competenze informatiche degli utenti sono spesso una
parte minore dei loro curricula
 complessità tollerabile, standardizzazione
• un difetto nel software può far perdere tempo e denaro
 qualità e affidabilità
• ...e naturalmente il costo delle soluzioni
 tempo di sviluppo
Il futuro dell’automazione (pessimista)
• Secondo Vyatkins, nel prossimo futuro (5 anni) crescerà
la complessità informatica dei componenti industriali
Cosa succederà?
– Aumenterà la potenziale flessibilità delle soluzioni
(più linguaggi di programmazione, più formati dei dati,
più standard di comunicazione).
– Le nuove leve tenderanno a trascurare l’ampia
eredità nel campo del software per l’automazione.
– Il risultato sarà una babele di soluzioni che diminuirà
l’affidabilità e la qualità dei sistemi.
• Come garantire la qualità e l’affidabilità del software
al crescere della complessità?
L’informatica: un settore particolare
• L’informatica (computer science) è una scienza giovane
(1940-). L’ingegneria informatica (computer/software
engineering) e la produzione non-artigianale di software
cominciarono nel 1960. L’industria del software
esplode successivamente (1980-).
• Non ci sono state ancora due generazioni di ingegneri;
inoltre la creazione del software è sostanzialmente
diversa da altre attività ingegneristiche.
• Le tecnologie informatiche hanno una vita breve
paragonabile a quella di un singolo progetto.
• In Italia il 30-40% dei progetti è abbandonato, è
completato in ritardo o fuori budget.
Il costo dei difetti nel software
• Spesso per il software di uso consumer il costo dei
difetti (bug) non viene quantificato.
– Il 30% dei lavoratori italiani usa il computer. Se
ognuno perde 1 ora a settimana (su 40) per i bug, 0.3
/ 40 = 0.1% del PIL = 1200mil = 1 miliardo di euro.
Questo è un costo nascosto.
• Però in alcuni casi il costo dei difetti è evidente:
– L’esempio classico: l’esplosione di un razzo Ariane
(1996) dovuto ad un buffer overflow.
– Automazione di apparecchiature mediche.
– Nell’industria il costo di un impianto fermo è
immediatamente quantificabile.
Informatica: alcuni punti fermi
Cosa ci ha lasciato mezzo secolo di informatica riguardo il
processo di produzione del software:
• Gli approcci modulari / con componenti riducono il
tempo di sviluppo e la complessità.
• La standardizzazione dei linguaggi di programmazione,
dei formati dei dati e dei linguaggi di modellazione
contribuiscono a creare una cultura unica di cui tutti
beneficiano.
• Quando sono utilizzabili, sono utili gli strumenti per:
verifica formale del software, progettazione assistita.
• Norme e strumenti sono inutili senza adeguate
metodologie di sviluppo.
I temi caldi del momento: il software libero, l’open source,
la brevettabilità del software, la brevettabilità delle idee.
L’approccio orientato ai componenti (1/3)
• Gli informatici invidiano il lavoro degli elettronici. Infatti il
progettista elettronico:
– può progettare un circuito servendosi di un CAD
– sceglie i componenti discreti/integrati da cataloghi
– può simulare il comportamento del circuito
• Quindi a fine giornata l’elettronico è felice:
– ha riutilizzato il lavoro di altri
– può verificare formalmente il suo lavoro
– ciò che ha prodotto è facilmente documentabile e
riutilizzabile
• Mentre l’elettronico torna a casa felice, l’informatico fa le
ore piccole per correggere “quell’ultimo bug”.
L’approccio orientato ai componenti (2/3)
• Un approccio a componenti si basa sul principio DIVIDE
ET IMPERA: è più facile risolvere tanti problemi semplici
che un unico grande problema complesso.
– Ma quanto è facile mettere insieme tante piccole soluzioni?
• Di fatto, la definizione di “componenti informatici” che
fornisca pieno riutilizzo / documentabilità / componibilità
come i componenti elettronici in generale non ha
successo:
– algoritmi e strutture dati sono complessi.
– l’interfaccia tra i componenti (formato dei dati) è più complicata.
– un computer è una macchina sequenziale e il parallelismo deve
essere implementato esplicitamente.
L’approccio orientato ai componenti (3/3)
• Un approccio basato su componenti è l’approccio objectoriented (orientato agli oggetti).
• Negli anni ‘70-'80 un concetto ormai assodato era la
struttura = insieme di dati primitivi
• Alcuni linguaggi (Ada/Delphi/C++) introdussero il
concetto di classe:
classe = struttura + algoritmi di manipolazione
• L’object-oriented programming nasce quindi come
tecnologia; diventa successivamente paradigma e si
arriva alla visione che
sistema = una collezione di oggetti che interagiscono
tramite scambio di messaggi
La via verso il successo
• Come garantire la qualità e l’affidabilità del
software per l’automazione al crescere della
complessità?
–
–
–
–
–
–
–
–
linguaggi di programmazione standard IEC 61331,...
approccio a componenti
IEC 61499, OO
integrazione dei componenti
Fieldbus
linguaggi di modellazione standard IEC 61499, UML
strumenti per verifica formale
IEC 61499
strumenti per progettazione assistita
IEC 61499
metodologie di sviluppo
???
???
lungimiranza e cultura della qualità
Indice
1) Riflessioni sulle problematiche del
software nell’automazione.
2) La norma IEC 61499
3) Un semplice caso di studio
4) Approccio object-oriented
5) Il linguaggio UML
6) Un semplice caso di studio (reprise)
7) Conclusioni
I due volti di IEC 61499
• I due volti di IEC 61499:
– IEC 61499 per modellare: “Lo scopo principale di
IEC 61499 non è quello di essere una metodologia di
programmazione ma di definire in modo formale
concetti, modelli e terminologia per descrivere modelli
di sistemi distribuiti”
– IEC 61499 per sviluppare: Vyatkins
• D’altronde la modellazione è il primo passo
necessario per arrivare a strumenti di
programmazione.
• Non si parla ancora di metodologie di sviluppo.
IEC 61499: compromessi del modello
•
Come tutti i modelli, c’è sempre un compromesso tra:
generico  dominio particolare
semplice  complesso
flessibile  rigido
informale  formale
sintetico  estensivo
analisi sintesi  simulazione
•
Per esempio:
– Schemi elettrici: dominio particolare, semplice, rigido, formale,
estensivo, sintesi/simulazione.
– Diagrammi dei sistemi di controllo: generico, flessibile,
informale, sintetico, analisi/sintesi.
– IEC 61499: generico, semplice, rigido, formale, sintetico,
sintesi/simulazione.
IEC 61499: compromessi della norma
•
Cosa influenza la creazione e la fortuna degli standard?
– Strategie commerciali
– Politiche (inter)nazionali
– Un buon tempismo
– Appoggio accademico
•
Alcuni esempi:
–
–
–
–
I tempi giusti, la snellezza e l’appoggio accademico: ISO/OSI vs. TCP.
Lo standard nuoce ai monopolisti: il boicottaggio di Java da parte di
Microsoft.
L’influenza della politica: l’indecisione europea tra PAL/SECAM/NTSC
causa 10 anni di ritardo nell’introduzione della TV a colori in Italia.
Lo standard impedisce la segmentazione del mercato: lo strano caso
degli alimentatori dei portatili/cellulari.
IEC 61499: compromessi della norma
• Il mondo è fatto di compromessi:
Interessi degli utenti  interessi dei produttori
evoluzione rivoluzione
punto di arrivo  punto di partenza
– IEC 61331: interessi degli utenti, evoluzione, punto di
arrivo.
– IEC 61499: evoluzione, punto di partenza.
IEC 61499: Modello funzionale
• Un sistema è un insieme
di blocchi funzione che
collaborano e si
coordinano attraverso
degli eventi.
• Agli eventi sono
associati dati, e quindi è
opportuno parlare di
scambio di messaggi.
• La rappresentazione
grafica è equivalente alla
rappresentazione
testuale.
Eventi
In entrata
INIT
Eventi in
uscita
PRESSED
BottoneA
Nome
istanza
INT
PIANO
Associazione
dati / eventi
RAPPRESENTAZIONE
TESTUALE
..........
IEC 61499: Execution Control Chart
• Il comportamento interno
è descritto dall’Execution
Control Chart (diagramma
del controllo
dell’esecuzione).
• Gli eventi condizionano la
transizione tra stati.
Questo basta a modellare
gran parte dei blocchi.
• E’ possibile associare
degli algoritmi (ST o Java)
per i blocchi che ne fanno
uso.
Evento in
entrata
Stato iniziale
START
E_IN
1
RESPONDING
Stato di computazione
ALGO()
Algoritmo
Transizione
istantanea
E_OUT
Evento
In uscita
Esempio: elemento rendez-vous
• Il componente aspetta E_IN1 e E_IN2 prima di far partire
E_OUT.
START
E_IN1
E_IN2
E_OUT
Rendez
-vous
E_IN2
E_IN1
1
WAIT_2
WAIT_1
E_IN1
E_IN2
FIRE
E_OUT
Tipi di blocchi
• Esistono 3 tipi di blocchi, graficamente simili:
– Blocchi semplici: comportamento definito da ECC e
algoritmi.
– Blocchi di interfaccia: realizzano interfacciamento
con hardware e dispositivi di comunicazione.
– Blocchi composti: unione di più blocchi
(ricorsivamente).
• E’ incoraggiata la composizione fra blocchi. Da pochi
blocchi base è possibile avere comportamenti complessi
(la composizione favorisce il riutilizzo e l’eleganza).
I blocchi di interfaccia di servizio
• I blocchi di interfaccia sono modellati come rispondenti a
richieste di servizio.
REQ
START
RSP
Interface
REQ
1
VALUE
RESPONDING
BUS/ETHERNET
LEGGI()
RSP
SENSORE
• E’ modellata similmente l’interfaccia verso le reti e verso
i dispositivi fisici.
Modello delle risorse
• IEC 61499 separa il modello di esecuzione (blocchi,
eventi, composizione) dal modello delle risorse che
supportano l’esecuzione.
• L’hardware è diviso in:
– Risorsa: supporta l’esecuzione di un blocco funzione (es: una
scheda, uno dei processori del PC)
– Dispositivo: può avere più risorse. (es: un PLC con più schede,
un PC industriale con più processori)
• Le applicazioni sono costituite da reti di blocchi che
possono essere distribuite su più dispositivi (ma un
blocco su una sola risorsa)
– La norma non è ancora completa per quanto riguarda
l’indirizzamento e le modalità di comunicazione di dispositivi
diversi.
Indice
1) Riflessioni sulle problematiche del
software nell’automazione.
2) La norma IEC 61499
3) Un semplice caso di studio
4) Approccio object-oriented
5) Il linguaggio UML
6) Un semplice caso di studio (reprise)
7) Conclusioni
Scenario
Azionamento
Encoder
Freno di
sicurezza
03
Display interno
4
3
Estensimetro
2
Porte ascensore
1
Bottoni di
comando
03
Luce di
conferma
Bottone di
prenotazione
Metodologia di sviluppo
Per la particolarità di IEC 61499 sembra coerente una
metodologia di sviluppo bottom up – “dal basso in
alto” – perché incoraggia l’aggregazione di blocchi
semplici in costrutti complessi e riutilizzabili.
Sequenza:
1.
2.
3.
4.
5.
Definizione dei blocchi di interfaccia.
Loop di controllo dell’azionamento.
Controllore multiplo.
Sequenziamento operazioni.
Scheduling (pianificazione del servizio).
Blocchi di interfaccia – Sensori (1/2)
I sensori seguono lo schema richiesta/risposta.
REQ
START
RSP
Sensore
REQ
1
VALUE
RESPONDING
Nota: per chiarezza sono stati omessi i segnali standard di
inizializzazione/spegnimento
LEGGI()
RSP
Blocchi di interfaccia – Sensori (2/2)
Rappresentazione di encoder ed estensimetro.
REQ
RSP
Encoder
ALTEZZA
REQ
RSP
Estensimetro
PESO
Blocchi di interfaccia – Attuatori
• Non siamo interessati ai particolari
dell’azionamento. Ipotizziamo che
sia comandato in coppia e che
abbia un segnale di emergenza.
SET
ALARM
Azionamento
COPPIA
• Immaginiamo che il produttore
delle porte ci abbia fornito questo
blocco.
OPEN
OPEN_OK
CLOSE
CLOSE_OK
Door
Definizioni blocchi di interfaccia - Bottoni
03
INIT
4
PRESSED
BottoneA
3
2
INT
1
03
INT
PIANO
PIANO
ID_ASC
ID_ASC
INIT
PRESSED
BottoneP
BOOL
INT
SU/GIU SU/GIU
PIANO
PIANO
BOOL
INT
Blocchi di interfaccia - Display
CHANGE
03
Display
4
3
INT
2
NUMBER
1
03
SET
Luci
BOOL
ON/OFF
Blocco PID
Troveremo questo blocco nelle librerie standard. Gli eventi
principali configurano i parametri e aggiornano l’uscita.
INIT
UPDATE
UPDATE
SET_REF
PID
KP
KI
KD
…
VALUE
REF
VALUE
Predisposizione Automatica
Nelle librerie saranno presenti anche
blocchi per l’auto/self tuning:
programmi per la regolazione dei
parametri off/on –line.
Pid
+
Autotuning
La predisposizione consiste in tre passi:
1. Osservazione del comportamento del sistema da controllare
• Scelta del modello (semplice: FOPDT,SOPDT)
• identificazione dei parametri
2. Descrizione del comportamento desiderato ad anello chiuso.
3. Calcolo dei parametri del regolatore:
• Model-based (metodi di Haalman, Dahlin)
• Characteristic-based (metodi di Ziegler-Nichols)
• Ruled-based (soft-computing)
Altri blocchi utili
• Questo blocco innesca la
catena di eventi che porta al
calcolo e l’aggiornamento delle
uscite.
INIT
STOP
CLOCK
Clock
REAL
• Esempio di un blocco che
calcola la derivata in banda di
un segnale.
T
INIT
UPDATE
UPDATE
Deriv
OMEGA0
REAL
REAL
OMEGA1
VALUE
VALUE
Semplice loop di controllo
INIT
CLOCK
REQ
RSP
STOP
Clock
Encoder
T
INIT
UPDATE
SET_REF
UPDATE
ALARM
SET
Azionamento
PID
KP
KI
KD
…
VALUE
REF
VALUE
COPPIA
Il loop di controllo incapsulato
INIT
ALARM
STOP
SET_REF
KP
UPDATE
CONTROL
LOOP
KI
KD
T
DERIV
REF
ALTEZZA
Sequenziamento delle operazioni
•
Sequenziamento delle operazioni.
1.
2.
3.
4.
5.
6.
L’ascensore è al piano.
Prenotazione.
Chiusura delle porte.
Controllo in velocità nel mezzo del percorso.
Controllo in posizione per frenatura.
Apertura delle porte.
Controllo dell’ascensore – dal di dentro
START
1
WAITING
E_AL_PIANO
CLOSING
E_DOOR_CLOSE
SPEED
E_PID_INIT
POSITION
E_PID_INIT
OPENING
E_DOOR_OPEN
E_RICHIESTA
E_DOOR_CLOSED
E_UPDATE &
ALTEZZAPIANO
E_UPDATE &
ALTEZZA=PIANO
E_DOOR_OPENED
Sequenziamento
E_REQUEST
E_REQUEST_OK
E_DOOR_CLOSE_OK
E_DOOR_CLOSE
E_DOOR_OPEN_OK
E_DOOR_OPEN
E_PID_INIT
E_UPDATE
SEQUENCE
CONTROL
PIANO
ALTEZZA
RIF_ALTEZZA
PID_PARAMS
Sequenziamento
E_REQUEST_OK
E_REQUEST
E_DOOR_CLOSE
E_DOOR_OPEN
E_UPDATE
E_DOOR_OPEN_OK
E_PID_INIT
E_SET_REF
ALTEZZA
UPDATE
SET_REF
CONTROL
LOOP
SEQUENCE
CONTROL
PIANO
ALARM
INIT
E_DOOR_CLOSE_OK
RIF_ALTEZZA
REF
PID_PARAMS
PID_PARAMS
1ms
ALTEZZA
T
OPEN OPEN_OK
CLOSE CLOSE_OK
Door
FRENA
Freno
Controllo e sequenziamento
• Questo blocco incapsula tutto quello che
abbiamo progettato finora: controllo e
sequenziamento.
VAI
ARRIVATO
Ascensore
PIANO
Problemi di pianificazione del servizio
03
03
03
03
03
03
03
03
03
Blocco di scheduling
SCHEDULING
PRESSED
PRESSED
PRESSED
BottoneP
BottoneP
BottoneP
SU/GIU
SU/GIU
PIANO
SU/GIU
PIANO
PIANO
Molti bottoni di
prenotazione
INIT
PRESSED
INIT
PRESSED
INIT
PRESSED
BottoneA
BottoneA
BottoneA
PIANO
PIANO
PIANO
PIANO
ID_ASC ID_ASC
PIANO
PIANO
ID_ASC ID_ASC
ID_ASC ID_ASC
Molti bottoni di
comando
VAI
VAI
VAI
ARRIVATO
ARRIVATO
ARRIVATO
Ascensore1
Ascensore1
Ascensore1
PIANO
PIANO
PIANO
Molti ascensori
Blocco di scheduling
• L’interfaccia del blocco di scheduling:
E_PRENOTAZIONE
E_VAI
E_COMANDO
E_ARRIVATO
SCHEDULING
PIANO
SU/GIU
ID_ASCENSORE
PIANO
ID_ASCENSORE
Riassunto
Gerarchia dei function block:
SCHEDULING
DISPLAY
ASCENSORE
DOOR
PID
LOOP CONTROL
CLOCK
BUTTON
SEQUENCE
CONTROL
ENCODER AZIONAMENTO
BUTTON
DISPLAY
Evoluzione da IEC 61331
Anche nello standard precedente esistevano i
function block ma molti sono i cambiamenti dallo
standard precedente:
• Tramite gli eventi, nei diagrammi è stabilito l’ordine di
esecuzione; non c’è il problema dei loop.
• Non sono permesse variabili globali; ogni blocco
comunica con l’esterno solo tramite eventi/dati.
• Non c’era un’architettura standard per distribuire i
blocchi.
Un futuro felice
Il futuro con IEC 61499 sembra molto roseo:
• Esisteranno blocchi standard per domini specifici.
• Tutti i dispositivi (sensori e attuatori) saranno compatibili
a livello di interfaccia (fieldbus), e interscambiabili.
• Da una sola workstation si potranno monitorare e
riconfigurare le applicazioni in un impianto.
• Le applicazioni sviluppate saranno riutilizzabili.
• Saranno fattibili verifiche formali sulla correttezza dei
sistemi di controllo (esecuzione abbastanza veloce,
tolleranza ai guasti).
Indice
1) Riflessioni sulle problematiche del
software nell’automazione.
2) La norma IEC 61499
3) Un semplice caso di studio
4) Approccio object-oriented
5) Il linguaggio UML
6) Un semplice caso di studio (reprise)
7) Confronto
8) Conclusioni
Progettazione object oriented
• La progettazione software può essere rappresentata
come un insieme di oggetti che interagiscono
• Parole chiave nell’approccio OO:
– Classe
• Denota le caratteristiche comuni di entità che hanno uno stato e
un insieme di operazioni
• Un oggetto è un’istanza di una classe
– Attributi
• Lo stato di un oggetto è rappresentato da un insieme di attributi
– Metodi
• Le operazioni definite su un oggetto, che offrono servizi ad altri
oggetti
– Incapsulamento
– Ereditarietà
– Specializzazione (overriding)
– Polimorfismo
Incapsulamento
• Ogni classe ha due “aspetti”:
– uno esterno (“pubblico”) noto alle altre entità
– uno interno (“privato”)
• Livello esterno o interfaccia pubblica
– Specifica i messaggi che possono essere inviati agli
oggetti della classe
– Specifica i servizi che l’oggetto istanziato può fornire
– Rappresenta ciò che l’oggetto “sa fare” nello scenario
applicativo, le sue responsabilità
• Livello interno o privato
– Definisce le proprietà dell’oggetto (i dati) e le modalità
di trattamento di questi dati (i metodi)
Information hiding
• Normalmente gli oggetti nascondono la loro
struttura all’ambiente circostante
– Esempio: una macchinetta per il caffè da ufficio. Se
cambia l’implementazione il servizio rimane uguale
(Scelta, monete, ritiro)
– Esempio: algoritmo che calcola inversa di una matrice in
Matlab. Non interessa sapere quale particolare algoritmo
viene utilizzato ma che il risultato sia corretto
• Information hiding (occultamento della
complessità): Per usare un oggetto basta conoscere
le operazioni disponibili. Vantaggi:
– Semplicità d’uso.
– Effetti benefici sulla manutenzione del software: è
possibile apportare variazioni all’oggetto in modo
trasparente per le applicazioni che lo usano.
Sviluppo orientato agli oggetti
• L’analisi, la progettazione e la programmazione
object-oriented sono legate ma distinte:
– OOA (o.-o. analysis) riguarda l’analisi del dominio di
applicazione con un modello ad oggetti.
– OOD (o.-o. design) riguarda la progettazione di un
modello orientato ad oggetti del sistema.
– OOP (o.-o. programming) riguarda la realizzazione del
progetto usando uno specifico linguaggio orientato ad
oggetti (C++, Ada, Java, Eiffel, ecc.)
Indice
1) Riflessioni sulle problematiche del
software nell’automazione.
2) La norma IEC 61499
3) Un semplice caso di studio
4) Approccio object-oriented
5) Il linguaggio UML
6) Un semplice caso di studio (reprise)
7) Confronto
8) Conclusioni
Linguaggi di modellazione
• Perché si utilizzano i linguaggi di modellazione
per il software?
–
–
–
–
Facilità di sviluppo
Tempi di sviluppo più brevi
Documentazione migliore
Numero di bug inferiore, dovuto ad una fase di test
migliorata
• La modellazione del software richiede più tempo
dello sviluppo ma è anche vero che il tempo di
sviluppo può essere drasticamente ridotto
mediante la modellazione e la
documentazione del software.
• Meglio prevenire che curare!
Che cos’è l’UML?
L’UML è un linguaggio di modellazione, non una
metodologia di sviluppo.
• Il linguaggio di modellazione è la notazione usata dalle
metodologie per esprimere le caratteristiche di un
progetto
• L’UML costituisce una notazione universale per
rappresentare qualunque tipo di sistema software,
hardware, organizzativo
• Ha avuto un processo di evoluzione: è stato definito
con il contributo di molti metodologi e delle più importanti
società di software mondiali
Perché si usa UML?
• Le notazioni servono a comunicare :
– Il linguaggio naturale è troppo impreciso e quando i
concetti si fanno complessi tende a ingarbugliarsi.
– Il codice è preciso, ma troppo dettagliato
• Si usa UML :
– per comunicare concetti in modo più chiaro di quanto
si potrebbe fare altrimenti
– quando si desidera un certo grado di dettaglio ma non
ci si vuole perdere nei dettagli
• I diagrammi sono più immediati delle parole
Storia dell’UML
Lo Unified Modeling Language (UML) è il successore di una serie di
metodologie di analisi e progettazione orientate agli oggetti apparse tra
la fine degli anni ’80 e i primi anni ’90.
Nov ‘97
UML è approvato dall’OMG
Set ‘97
UML 1.1
Gen ‘97
IBM,
Platinum
e altri
UML 1.0
Giu ‘96
UML 0.9
Ott ‘95
Unified Method 0.8
Microsoft,
Oracle, HP
e altri
Jacobson
Rumbaugh
Booch
Storia dell’UML
L’UML è stato standardizzato dall’OMG, Object Management Group, ed
è ora riconosciuto come uno standard OMG.
UML
2.0
2004
2003
UML
1.4
2001
1999
1998
UML
1.3
UML 1.2
UML
1.5
versione attuale
Contributi all’UML
UML e meta-modello
• L’UML nella sua incarnazione attuale definisce una
notazione e un meta-modello
• La notazione è l’aspetto grafico dei modelli. Rappresenta
la sintassi del linguaggio di modellazione
• UML è basato su un meta-modello integrato, composto
da numerosi elementi, collegati tra loro secondo regole
precise
• Utilizzando gli elementi del meta-modello è possibile
creare i modelli per il sistema da rappresentare
• Molti elementi hanno un’icona che li rappresenta
graficamente
• Gli elementi del meta-modello possono comparire in
diagrammi di diverso tipo
• Le regole permettono verifiche di correttezza
Sviluppo basato su modelli
Cos’è un modello?
• è una rappresentazione astratta di un
sistema che lo descrive in modo completo
secondo un specifico punto di vista.
• è una semplificazione della realtà.
Perché modelliamo?
• Divide et impera: tramite i modelli ci
focalizziamo su un solo aspetto alla volta
• ogni modello può essere espresso a differenti
livelli di precisione
• per un sistema non banale:
 non un solo modello
 ma un piccolo insieme di modelli, che
possono essere costruiti e studiati
separatamente, ma che sono strettamente
interrelati
Come viene utilizzato UML
• UML come abbozzo (sketch)
• UML come progetto dettagliato (blueprint)
• UML come linguaggio di programmazione
UML come abbozzo
• Si utilizza UML per aiutare a documentare alcuni aspetti
di un sistema
– prima che il sistema sia sviluppato (forward engineering)
– partendo da un sistema già esistente (reverse engineering)
• Lo scopo principale è favorire la comprensione e la
comunicazione nelle discussioni
• Criteri fondamentali
– Selettività
• Solo alcuni aspetti del sistema sono modellati graficamente
• Qualsiasi informazione può essere soppressa ( l’assenza di
qualcosa non significa che non esista)
– Espressività
• Diagrammi intesi come figure
• I diagrammi sono spesso creati rapidamente e in modo
collaborativo (lavagna)
UML come progetto dettagliato
• Si utilizza UML per guidare la realizzazione o la
manutenzione di un sistema
– Prima che il sistema sia stato sviluppato (forward engineering)
– Partendo da un sistema già esistente (reverse engineering)
• Lo scopo principale è fornire ai programmatori un
modello dettagliato (blueprint)
– Approccio ispirato a altre branche dell’Ingegneria
• Criteri fondamentali
– Completezza
– Non ambiguità
• I diagrammi creati fanno parte della documentazione del
sistema e vanno modificati insieme al sistema stesso
– Utilizzo di strumenti CASE specializzati
UML come linguaggio di programmazione
• Si utilizza UML per compilare direttamente i diagrammi
in formato eseguibile
– Rappresentazione UML e codice sorgente coincidono
• Nessuna distinzione tra forward e reverse engineering
• Lo scopo principale è permettere agli sviluppatori di
programmare in modo visuale, indipendentemente dalla
piattaforma software adottata
– MDA (Model Driven Architecture)
• Gli sviluppatori creano un PIM (Platform Independent Model)
• Il Pim è trasformato (semi-)automaticamente in un PLM (Platform
Specific Model)
• Il PLM è trasformato automaticamente in codice specifico di una
piattaforma (J2EE, .NET)
• Strumenti molto sofisticati ma non ancora maturi
MDA vs. Round trip engineering
• MDA (Model Driven Architecture):
– è un’architettura per la generazione automatica di
codice, definita e gestita dall’OMG
– Idealmente, con l’utilizzo di strumenti MDA, i sistemi
possono essere generati, completi, a partire da UML,
senza dover scrivere codice
• Round trip engineering:
– Produzione manuale del codice a partire da un
modello UML
– Ri-produzione del modello UML a partire dal codice
esistente
– Solo per linguaggi “object based”
Benefici portati dall’UML
• superamento della “guerra dei metodi”
• il meta-modello comune favorisce la possibilità
di comunicazione fra strumenti di supporto alla
progettazione, e più in generale tra i diversi
ambienti utilizzabili dai progettisti nello sviluppo
• risposta ai problemi legati allo sviluppo di sistemi
complessi con ambienti visuali
– attenzione alla progettazione, non solo alla codifica
– attenzione sul processo di lavoro e sugli approcci
utilizzati, non solo sulle tecnologie
Benefici portati dall’UML
• Riduzione dei tempi di sviluppo di un sistema
software
• Diminuzione dei costi di sviluppo
• Robustezza e affidabilità del software
• Visione più completa e coesa del sistema
• Stesura del codice facilitata e più efficiente
• Previsione, anticipazione e individuazione degli
errori
• Facile manutenzione
• Portabilità del modello
• Riusabilità ed estendibilità del modello
UML va adattato alle proprie esigenze
• le realtà che sviluppano software sono
molto eterogenee
• Differenti esigenze di:
– Documentazione
– Comunicazione
– Formalizzazione
• i progetti non sono tutti uguali:
– Dimensioni, tipologia, criticità…
• UML è sufficientemente complesso per
potersi adottare a tutte le esigenze
Diagrammi UML
• Diagrammi strutturali:
– Diagramma delle classi
– Diagramma degli oggetti
– Diagramma dei
componenti
– Diagramma delle
strutture composite
– Diagramma di
deployment
– Diagramma dei package
• Diagrammi
comportamentali:
–
–
–
–
–
–
–
Diagramma dei casi d’uso
Diagramma di stato
Diagramma delle attività
Diagramma di sequenza
Diagramma di comunicazione
Diagramma dei tempi
Diagramma di sintesi
dell’interazione
Diagramma delle classi
• Rappresenta le classi di oggetti del sistema con i loro
attributi e operazioni
• Mostra le relazioni tra le classi (associazioni, aggregazioni
e gerarchie di specializzazione/generalizzazione)
• Può essere utilizzato a diversi livelli di dettaglio (in analisi
e in disegno)
• Classe : è la descrizione di un insieme di oggetti(elementi
di una classe) che condividono determinati caratteristiche
comuni
• Attributi : rappresentano le proprietà che sono condivise
da tutti gli oggetti appartenenti ad una data classe
• Operazioni : rappresentano servizi che possono essere
richiesti a qualche oggetto appartenente alla classe e che
modificano il comportamento del sistema a cui l’oggetto
appartiene
Diagramma delle classi
• Relazioni:
– Associazione : connessione concettuale tra due
classi
– Aggregazione : rappresenta una gerarchia in cui una
classe detta “intero” è al di sopra di altre classi dette
“componenti”
– Composizione : aggregazione di tipo più forte in cui
un componente può appartenere soltanto ad un intero
– Realizzazione : è una relazione tra una classe e
un’interfaccia
– Ereditarietà : è una relazione in cui una “classe figlia”
può ereditare gli attributi e le operazioni da una
classe più generica detta “classe padre”
Diagramma delle classi esempio
Pag. Contanti
Pagamento
Prodotto
importo
1
descrive
aggregazione
Pag. Carta Credito
1
riferito a
1
Vendita
0..*
ha
data
Riga vendita
specializzazione /
ora
1..*
generalizzazione
1
crea_vendita()
*
1
utilizzato da
Cassiere
associazione
POST
1
1..*
1
*
avviato da
1
Negozio
nome
1
Amministratore
indirizzo
Diagramma dei casi d’uso
• Mostra:
– le modalità di utilizzo del sistema (casi d’uso)
– gli attori del sistema
– le relazioni tra attori e casi d’uso
• Scenario : sequenza di passi che descrivono
l’interazione tra un utente e il sistema
• Un caso d’uso
– rappresenta un possibile “modo” di utilizzo del sistema
– può racchiudere più scenari
– rappresenta una visione esterna del sistema
• Utile quando si parla con persone che non si
intendono di software (committenti)
Diagramma dei casi d’uso
attore: un
utilizzatore
del sistema
acquistare articoli
log in
cliente
rimborsare articoli venduti
cassiere
caso d'uso: un
"modo" di utilizzare il
sistema
Diagrammi di sequenza
• Un diagramma di sequenza rappresenta la
sequenza temporale delle interazioni che
avvengono fra gli oggetti del sistema
• Mostra gli oggetti coinvolti specificando la
sequenza temporale dei messaggi che gli
oggetti si scambiano
• E’ un diagramma di interazione: evidenzia
come un caso d’uso è realizzato tramite la
collaborazione di un insieme di oggetti
Diagramma di sequenza esempio
oggetto
: Vendita
: POST
: Riga vendita
: Prodotto
: cassiere
registra_articolo (prodotto_id, qta)
[nuova vendita] crea vendita ( )
porzione del caso d'uso
[vendita
in corso] aggiungi riga vendita ( )
"Acquistare articoli"
relativa alla
crea riga vendita (prodotto_id, qta)
registrazione articoli
messaggio
Diagrammi di collaborazione
• E’un diagramma di interazione: rappresenta un
insieme di oggetti che collaborano per realizzare
il comportamento di uno scenario di un caso
d’uso
• A differenza del diagramma di sequenza, mostra
i link (legami) tra gli oggetti che si scambiano
messaggi, mentre la sequenza di tali messaggi
è meno evidente
• può essere utilizzato in fasi diverse (analisi,
disegno di dettaglio)
Diagramma di collaborazione esempio
2: [nuova vendita] crea vendita ( )
3: [vendita in corso] aggiungi riga vendita ( )
1: registra_articolo (prodotto_id, qta)
: POST
: Vendita
: cassiere
4: crea riga vendita (prodotto_id, qta)
5: get_prezzo (prodotto_id)
: Riga
vendita
link
: Prodotto
oggetto
Diagrammi di stato
• è normalmente utilizzato per modellare il ciclo di vita degli
oggetti di una singola classe
• mostra gli eventi che causano la transizione da uno stato
all’altro, le azioni eseguite a fronte di un determinato
evento
• quando un oggetto si trova in un certo stato può essere
interessato da determinati eventi (e non da altri)
• è opportuno utilizzarlo solo per le classi che presentano
un ciclo di vita complesso e segnato da una
successione ben definita di eventi
• Aiuta gli analisti, i progettisti e gli sviluppatori a capire il
comportamento degli oggetti in un sistema
• Gli sviluppatori devono tradurre tale comportamento in
software
Diagramma di stato esempio
aggiungi riga ordine
stato iniziale
acquisisci ordine
Transizione
di stato
acquisito
stato
verifica ordine
annullato
verificato e completato
scadenza termini di pagamento
dopo un anno
stato finale
pagamento ricevuto
dopo un anno
pagato
spedizione al cliente
spedito
Uso dei diagrammi UML
• DEFINIZIONE DELLE ATTIVITA’: attraverso colloqui con
•
•
•
•
l’utilizzatore vengono analizzate in modo dettagliato le
attività fondamentali del sistema, definendo un
diagramma delle attività
ANALISI DEL SISTEMA: vengono definiti gli attributi e le
operazioni delle varie classi che compongono il sistema,
per realizzare un diagramma delle classi
CORRELAZIONE TRA I SISTEMI: vengono identificate le
relazioni di dipendenza tra i vari sistemi attraverso la
realizzazione di un diagramma di deployment
PRESENTAZIONE DEI RISULTATI: terminata la raccolta delle
informazioni vengono presentati i risultati dell’analisi
all’utilizzatore
COMPRENSIONE DELL’UTILIZZO DEL SISTEMA: attraverso
colloqui con i potenziali utenti vengono definiti gli attori e
i relativi casi d’uso, per realizzare un diagramma dei
casi d’uso
Uso dei diagrammi UML
• ANALISI DELLE TRANSIZIONI DI STATO: durante la creazione
dei modelli vengono analizzate le eventuali transizioni di
stato di un oggetto, realizzando un diagramma di stato
• INTERAZIONE TRA GLI OGGETTI: per mettere in relazione
gli oggetti, definiti nei precedenti diagrammi, con le
transizioni di stato, si realizzano il diagramma di
sequenza e il diagramma di collaborazione
• ANALISI DELL’INTEGRAZIONE DEL SISTEMA CON SISTEMI
PREESISTENTI: si sviluppa un diagramma di
distribuzione per definire l’integrazione con i sistemi
preesistenti o con altri sistemi con i quali è necessario
cooperare
• DEFINIZIONE DEGLI OGGETTI: dall’analisi del diagramma
delle classi viene generato il diagramma degli oggetti
• DEFINIZIONE DEI COMPONENTI: vengono visualizzati i
componenti del sistema e le loro dipendenze,
realizzando un diagramma dei componenti
Uso dei diagrammi UML
• REALIZZAZIONE DEL CODICE: con il diagramma
delle classi, il diagramma degli oggetti, il
diagramma delle attività e il diagramma dei
componenti a disposizione, viene realizzato dai
programmatori il codice per il sistema
• PROVE DEL CODICE
• COSTRUZIONE DELL’INTERFACCIA UTENTE E
COLLEGAMENTO AL CODICE: una volta che è a
disposizione il sistema funzionante e completo
con l’interfaccia utente
• INSTALLAZIONE DEL SISTEMA COMPLETO
SULL’HARDWARE APPROPRIATO
• PROVE SUL SISTEMA INSTALLATO
Indice
1) Riflessioni sulle problematiche del
software nell’automazione.
2) La norma IEC 614499
3) Un semplice caso di studio
4) Approccio object-oriented
5) Il linguaggio UML
6) Un semplice caso di studio (reprise)
7) Conclusioni
Sistema di controllo ascensori
• Consideriamo il sistema modellato
precedentemente con IEC 61499
Domande a cui vogliamo rispondere:
• Quale metodologia adottare per descrivere
il sistema secondo UML?
• Quali diagrammi utilizzare?
Diagramma dei casi d’uso
Diagramma delle classi - Driver
Diagramma delle classi - Generale
Diagramma delle classi – Azionamento Ascensore
Diagramma di sequenza prenotazione
Caso d’uso
Prenotare Ascensore
Diagramma di sequenza trasporto
Caso d’uso
Trasporto in Ascensore
Diagramma di sequenza allarme utente
Caso d’uso allarme generato da un utente
Diagramma di sequenza allarme interno
Caso d’uso allarme interno
Considerazioni finali
• L’UML è un linguaggio di modellazione
universale e in quanto tale può essere utilizzato
per qualsiasi tipo di sistema complesso
• Se utilizzato come strumento di analisi e
documentazione di sistemi nel campo
dell’automazione industriale permette di:
– Avere una visione generale del sistema a vari livelli di
dettaglio
– Capire come avvengono nel tempo le interazioni tra i
componenti del sistema generale
UML per l’analisi di un sistema di automazione
• Quali diagrammi utilizzare?
– Il diagramma dei casi d’uso perché:
• Definisce il comportamento del sistema (come il sistema
agisce e reagisce, come il sistema è visibile all’esterno)
• Descrive il sistema, l’ambiente e le relazioni tra i due
– Il diagramma delle classi perché:
• Fornisce una descrizione statica del sistema e delle relazioni
tra le classi (associazione,aggregazione e composizione)
• Visione generale del sistema
– I diagrammi di sequenza perché:
• Descrivono l’interazione temporale dei componenti di un
sistema
• Permettono di individuare facilmente le sequenze di
messaggi scambiati dagli elementi del sistema
Indice
1) Riflessioni sulle problematiche del
software nell’automazione.
2) La norma IEC 61499
3) Un semplice caso di studio
4) Approccio object-oriented
5) Il linguaggio UML
6) Un semplice caso di studio (reprise)
7) Conclusioni
IEC 61499 vs. UML
•La norma IEC 61499 e l’UML permettono di affrontare un
problema di automazione seguendo due approcci
complementari.
•Nell’esempio sviluppato la semplicità dell’applicazione
rendeva più immediato l’utilizzo dei function block.
•Comunque, anche tentando una soluzione di tipo bottom-up,
non si può prescindere da una visione d’insieme che UML può
fornire nel giusto livello di dettaglio.
•Infatti IEC 61499 non sembra scalabile con la complessità, i
progetti più complessi sembrano un groviglio di blocchi e fili.
Diceva l’uomo con la clava: “devo fare la guerra, non
ho tempo per conoscere le nuove tecnologie”
…e morì incenerito da un missile!
•L’avvento di nuovi standard e nuovi strumenti non deve essere inteso
come “ciò che si può anche non conoscere… le cose funzioneranno lo
stesso!”
•L’Automazione in Italia non può prescindere da un aggiornamento
continuo delle proprie conoscenze e un investimento totale nelle
innovazioni tecnologiche, se vuole veramente rilanciarsi a livello
internazionale.
•Se non si può vincere la sfida dei costi, si può vincere quella della
qualità?