Upload
dario-gentile
View
224
Download
0
Embed Size (px)
Citation preview
In collaborazione conAndrea Censi, Massimo Ferri e Luca Marchionni
Dipartimento diInformatica e Sistemistica
Alessandro DE CARLI
Anno Accademico 2006-07
UML E NORME IEC
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)
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
CAMPO
COORDINAMENTO
SUPERVISIONE
GESTIONE
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 object-oriented (orientato agli oggetti).
• Negli anni ‘70-'80 un concetto ormai assodato era lastruttura = 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– approccio a componenti– integrazione dei componenti– linguaggi di modellazione standard– strumenti per verifica formale– strumenti per progettazione assistita– metodologie di sviluppo– lungimiranza e cultura della qualità
IEC 61331,...
IEC 61499, OO
???
IEC 61499, UML
IEC 61499
IEC 61499
Fieldbus
???
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 complessoflessibile rigido
informale formalesintetico 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.
INIT PRESSED
BottoneA
PIANOINT
EventiIn entrata
Eventi inuscita
Associazionedati / eventi
Nomeistanza
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.
START
RESPONDING E_OUT
E_IN
1
ALGO()
Stato inizialeEvento inentrata
EventoIn uscita
Stato di computazione Algoritmo
Transizioneistantanea
Esempio: elemento rendez-vous
• Il componente aspetta E_IN1 e E_IN2 prima di far partire E_OUT.
E_IN1 E_OUT
Rendez-vous
E_IN2
START
WAIT_2
E_OUT
E_IN1
E_IN2
FIRE
WAIT_1
E_IN2
E_IN1
1
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 RSP
VALUE
Interface
START
RESPONDING RSP
REQ 1
LEGGI()
• E’ modellata similmente l’interfaccia verso le reti e verso i dispositivi fisici.
BUS/ETHERNET SENSORE
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
Bottone diprenotazione
Luce diconferma
Bottoni dicomando
Display interno
1
2
3
4
0 3
0 3
Azionamento
Encoder
Freno di sicurezza
Estensimetro
Porte ascensore
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. Definizione dei blocchi di interfaccia.2. Loop di controllo dell’azionamento.3. Controllore multiplo.4. Sequenziamento operazioni.5. Scheduling (pianificazione del servizio).
Blocchi di interfaccia – Sensori (1/2)
I sensori seguono lo schema richiesta/risposta.
REQ RSP
VALUE
Sensore
Nota: per chiarezza sono stati omessi i segnali standard di inizializzazione/spegnimento
START
RESPONDING RSP
REQ 1
LEGGI()
Blocchi di interfaccia – Sensori (2/2)
Rappresentazione di encoder ed estensimetro.
REQ RSP
ALTEZZA
Encoder
REQ RSP
PESO
Estensimetro
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
COPPIA
Azionamento
• Immaginiamo che il produttore delle porte ci abbia fornito questo blocco.
OPEN
CLOSE_OK
Door
CLOSE
OPEN_OK
Definizioni blocchi di interfaccia - Bottoni
INIT PRESSED
SU/GIU
BottoneP
SU/GIU
PIANO PIANO INTINT
BOOL BOOL
1
2
3
4
0 3
0 3
INIT PRESSED
PIANO
BottoneA
PIANOINT INT
ID_ASCID_ASC
Blocchi di interfaccia - Display
1
2
3
4
0 3
0 3
CHANGE
NUMBER
Display
INT
SET
ON/OFF
Luci
BOOL
Blocco PID
Troveremo questo blocco nelle librerie standard. Gli eventi principali configurano i parametri e aggiornano l’uscita.
INIT
KP
PID
KI
KD
…
UPDATE
VALUE
UPDATE
VALUE
SET_REF
REF
Predisposizione Automatica
Nelle librerie saranno presenti anche blocchi per l’auto/self tuning: programmi per la regolazione dei parametri off/on –line.
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)
Pid
+
Autotuning
Altri blocchi utiliINIT CLOCK
T
Clock
REAL
STOP
INITUPDATE
OMEGA0
Deriv
REAL
UPDATE
OMEGA1REAL VALUE VALUE
• Questo blocco innesca la catena di eventi che porta al calcolo e l’aggiornamento delle uscite.
• Esempio di un blocco che calcola la derivata in banda di un segnale.
Semplice loop di controllo
…
INITCLOCK
T
Clock
STOP
INIT
KPPID
KI
KD
UPDATE
VALUE
UPDATE
VALUE
SET_REF
REF
SET ALARM
COPPIA
Azionamento
REQ RSP
Encoder
Il loop di controllo incapsulato
INIT
KP
CONTROLLOOP
KI
KD
T
STOP
DERIV
UPDATE
ALTEZZA
SET_REF
REF
ALARM
Sequenziamento delle operazioni
• Sequenziamento delle operazioni. 1. L’ascensore è al piano.
2. Prenotazione.
3. Chiusura delle porte.
4. Controllo in velocità nel mezzo del percorso.
5. Controllo in posizione per frenatura.
6. Apertura delle porte.
Controllo dell’ascensore – dal di dentro
START
CLOSING
E_AL_PIANO
E_RICHIESTA
WAITING
SPEED
POSITION
OPENING
E_DOOR_CLOSED
E_UPDATE &ALTEZZAPIANO
1
E_UPDATE &ALTEZZA=PIANO
E_DOOR_OPENED
E_DOOR_CLOSE
E_PID_INIT
E_PID_INIT
E_DOOR_OPEN
Sequenziamento
E_REQUEST
SEQUENCECONTROL
E_DOOR_CLOSE_OK
RIF_ALTEZZA
E_DOOR_OPEN_OK
PIANO
PID_PARAMS
E_UPDATE
E_DOOR_OPEN
E_DOOR_CLOSE
E_PID_INIT
E_REQUEST_OK
ALTEZZA
Sequenziamento
OPEN
CLOSE_OK
Door
CLOSE
OPEN_OK
INIT
CONTROLLOOP
PID_PARAMS
T
UPDATE
ALTEZZA
SET_REF
REF
ALARM
1ms
E_REQUEST
SEQUENCECONTROL
E_DOOR_CLOSE_OK
RIF_ALTEZZA
E_DOOR_OPEN_OK
PIANO
PID_PARAMS
E_UPDATEE_DOOR_OPEN
E_DOOR_CLOSE
E_PID_INIT
E_REQUEST_OK
ALTEZZA
E_SET_REF
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
0 3 0 3 0 3
0 3 0 3 0 3
0 3 0 3 0 3
Blocco di scheduling
SCHEDULING
PRESSED
BottoneP
SU/GIU
PIANO
PRESSED
BottoneP
SU/GIU
PIANO
PRESSED
BottoneP
SU/GIU
PIANO
Molti bottoni di
prenotazione
INIT PRESSED
PIANO
BottoneA
PIANO
ID_ASCID_ASC
INIT PRESSED
PIANO
BottoneA
PIANO
ID_ASCID_ASC
INIT PRESSED
PIANO
BottoneA
PIANO
ID_ASCID_ASC
Molti bottoni di
comando
VAI ARRIVATO
Ascensore1
PIANO
VAI ARRIVATO
Ascensore1
PIANO
VAI ARRIVATO
Ascensore1
PIANO
Molti ascensori
Blocco di scheduling
• L’interfaccia del blocco di scheduling:
E_ARRIVATO
SCHEDULING
E_PRENOTAZIONE
PIANO
E_COMANDO
PIANO
E_VAI
SU/GIU
ID_ASCENSORE
ID_ASCENSORE
Riassunto
PID CLOCK AZIONAMENTOENCODER
SEQUENCECONTROL
DOOR
DISPLAY
BUTTONDISPLAYBUTTON
ASCENSORE
LOOP CONTROL
SCHEDULING
Gerarchia dei function block:
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 614993) Un semplice caso di studio4) Approccio object-oriented5) Il linguaggio UML6) Un semplice caso di studio (reprise)7) Confronto8) 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 614993) Un semplice caso di studio4) Approccio object-oriented5) Il linguaggio UML6) Un semplice caso di studio (reprise)7) Confronto8) 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
UML è approvato dall’OMGUML è approvato dall’OMGNov ‘97Nov ‘97
UML 1.1UML 1.1
IBM, IBM, PlatinumPlatinum
e altrie altri
Set ‘97Set ‘97
UML 1.0UML 1.0
Microsoft, Microsoft, Oracle, HPOracle, HP
e altrie altri
Gen ‘97Gen ‘97
UML 0.9UML 0.9
JacobsonJacobson
Giu ‘96Giu ‘96
Unified Method 0.8Unified Method 0.8
RumbaughRumbaugh BoochBooch
Ott ‘95Ott ‘95
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.
Storia dell’UML
L’UML è stato standardizzato dall’OMG, Object Management Group, ed è ora riconosciuto come uno standard OMG.
UML UML 1.41.4
20012001
UML UML 1.31.3
19991999
UML 1.2UML 1.219981998
UML UML 1.51.5
20032003
20042004UML UML 2.02.0
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
Amministratore
Cassiere
Negozio
nome
indirizzo
Prodotto
POST
*
1
*
1
avviato da
11 11
utilizzato da
1..*1
1..*1
Riga vendita
0..*
1
0..*
1
descrive
Vendita
data
ora
crea_vendita()
11*
1..* 11..* 1
ha
Pagamento
importo
11
1riferito a
Pag. Contanti
Pag. Carta Credito
associazione
aggregazione
specializzazione /
generalizzazione
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’usocaso 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
acquistare articoli
log incassierecliente
rimborsare articoli venduti
attore: un utilizzatore del sistema
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
: cassiere
: POST : Vendita : Riga vendita : Prodotto
porzione del caso d'uso
"Acquistare articoli"
relativa alla
registrazione articoli
registra_articolo (prodotto_id, qta)
[nuova vendita] crea vendita ( )
crea riga vendita (prodotto_id, qta)
[vendita in corso] aggiungi riga vendita ( )
oggetto
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
: cassiere
: POST : Vendita
: Riga vendita
: Prodotto
oggettolink
1: registra_articolo (prodotto_id, qta)
2: [nuova vendita] crea vendita ( )3: [vendita in corso] aggiungi riga vendita ( )
4: crea riga vendita (prodotto_id, qta)
5: get_prezzo (prodotto_id)
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
acquisito
pagato spedito
annullato
acquisisci ordine
aggiungi riga ordine
verificato e completato
spedizione al cliente
pagamento ricevuto
scadenza termini di pagamento
verifica ordine
dopo un anno
dopo un anno
stato
Transizione di stato
stato iniziale
stato finale
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’usoPrenotare Ascensore
Diagramma di sequenza trasporto
Caso d’usoTrasporto 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à?