in collaborazione con andrea censi, massimo ferri e luca marchionni dipartimento di informatica e...
TRANSCRIPT
![Page 1: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/1.jpg)
In collaborazione conAndrea Censi, Massimo Ferri e Luca Marchionni
Dipartimento diInformatica e Sistemistica
Alessandro DE CARLI
Anno Accademico 2006-07
UML E NORME IEC
![Page 2: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/2.jpg)
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
![Page 3: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/3.jpg)
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
![Page 4: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/4.jpg)
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.
![Page 5: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/5.jpg)
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.
![Page 6: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/6.jpg)
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
![Page 7: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/7.jpg)
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à?
![Page 8: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/8.jpg)
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.
![Page 9: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/9.jpg)
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.
![Page 10: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/10.jpg)
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.
![Page 11: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/11.jpg)
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”.
![Page 12: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/12.jpg)
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.
![Page 13: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/13.jpg)
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
![Page 14: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/14.jpg)
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
???
![Page 15: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/15.jpg)
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
![Page 16: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/16.jpg)
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.
![Page 17: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/17.jpg)
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.
![Page 18: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/18.jpg)
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.
![Page 19: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/19.jpg)
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.
![Page 20: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/20.jpg)
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..........
![Page 21: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/21.jpg)
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
![Page 22: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/22.jpg)
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
![Page 23: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/23.jpg)
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).
![Page 24: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/24.jpg)
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
![Page 25: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/25.jpg)
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.
![Page 26: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/26.jpg)
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
![Page 27: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/27.jpg)
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
![Page 28: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/28.jpg)
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).
![Page 29: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/29.jpg)
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()
![Page 30: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/30.jpg)
Blocchi di interfaccia – Sensori (2/2)
Rappresentazione di encoder ed estensimetro.
REQ RSP
ALTEZZA
Encoder
REQ RSP
PESO
Estensimetro
![Page 31: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/31.jpg)
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
![Page 32: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/32.jpg)
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
![Page 33: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/33.jpg)
Blocchi di interfaccia - Display
1
2
3
4
0 3
0 3
CHANGE
NUMBER
Display
INT
SET
ON/OFF
Luci
BOOL
![Page 34: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/34.jpg)
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
![Page 35: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/35.jpg)
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
![Page 36: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/36.jpg)
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.
![Page 37: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/37.jpg)
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
![Page 38: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/38.jpg)
Il loop di controllo incapsulato
INIT
KP
CONTROLLOOP
KI
KD
T
STOP
DERIV
UPDATE
ALTEZZA
SET_REF
REF
ALARM
![Page 39: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/39.jpg)
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.
![Page 40: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/40.jpg)
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
![Page 41: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/41.jpg)
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
![Page 42: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/42.jpg)
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
![Page 43: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/43.jpg)
Controllo e sequenziamento
• Questo blocco incapsula tutto quello che abbiamo progettato finora: controllo e sequenziamento.
VAI ARRIVATO
Ascensore
PIANO
![Page 44: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/44.jpg)
Problemi di pianificazione del servizio
0 3 0 3 0 3
0 3 0 3 0 3
0 3 0 3 0 3
![Page 45: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/45.jpg)
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
![Page 46: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/46.jpg)
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
![Page 47: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/47.jpg)
Riassunto
PID CLOCK AZIONAMENTOENCODER
SEQUENCECONTROL
DOOR
DISPLAY
BUTTONDISPLAYBUTTON
ASCENSORE
LOOP CONTROL
SCHEDULING
Gerarchia dei function block:
![Page 48: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/48.jpg)
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.
![Page 49: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/49.jpg)
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).
![Page 50: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/50.jpg)
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
![Page 51: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/51.jpg)
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
![Page 52: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/52.jpg)
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)
![Page 53: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/53.jpg)
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.
![Page 54: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/54.jpg)
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.)
![Page 55: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/55.jpg)
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
![Page 56: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/56.jpg)
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!
![Page 57: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/57.jpg)
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
![Page 58: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/58.jpg)
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
![Page 59: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/59.jpg)
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.
![Page 60: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/60.jpg)
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
![Page 61: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/61.jpg)
Contributi all’UML
![Page 62: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/62.jpg)
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
![Page 63: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/63.jpg)
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à.
![Page 64: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/64.jpg)
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
![Page 65: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/65.jpg)
Come viene utilizzato UML
• UML come abbozzo (sketch)
• UML come progetto dettagliato (blueprint)
• UML come linguaggio di programmazione
![Page 66: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/66.jpg)
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)
![Page 67: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/67.jpg)
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
![Page 68: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/68.jpg)
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
![Page 69: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/69.jpg)
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”
![Page 70: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/70.jpg)
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
![Page 71: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/71.jpg)
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
![Page 72: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/72.jpg)
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
![Page 73: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/73.jpg)
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
![Page 74: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/74.jpg)
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
![Page 75: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/75.jpg)
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”
![Page 76: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/76.jpg)
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
![Page 77: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/77.jpg)
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)
![Page 78: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/78.jpg)
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
![Page 79: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/79.jpg)
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
![Page 80: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/80.jpg)
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
![Page 81: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/81.jpg)
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)
![Page 82: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/82.jpg)
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)
![Page 83: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/83.jpg)
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
![Page 84: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/84.jpg)
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
![Page 85: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/85.jpg)
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
![Page 86: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/86.jpg)
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
![Page 87: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/87.jpg)
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
![Page 88: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/88.jpg)
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
![Page 89: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/89.jpg)
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?
![Page 90: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/90.jpg)
Diagramma dei casi d’uso
![Page 91: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/91.jpg)
Diagramma delle classi - Driver
![Page 92: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/92.jpg)
Diagramma delle classi - Generale
![Page 93: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/93.jpg)
Diagramma delle classi – Azionamento Ascensore
![Page 94: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/94.jpg)
Diagramma di sequenza prenotazione
Caso d’usoPrenotare Ascensore
![Page 95: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/95.jpg)
Diagramma di sequenza trasporto
Caso d’usoTrasporto in Ascensore
![Page 96: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/96.jpg)
Diagramma di sequenza allarme utente
Caso d’uso allarme generato da un utente
![Page 97: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/97.jpg)
Diagramma di sequenza allarme interno
Caso d’uso allarme interno
![Page 98: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/98.jpg)
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
![Page 99: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/99.jpg)
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
![Page 100: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/100.jpg)
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
![Page 101: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/101.jpg)
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.
![Page 102: In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07](https://reader036.vdocuments.pub/reader036/viewer/2022062312/5542eb57497959361e8c1a15/html5/thumbnails/102.jpg)
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à?