In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e...

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


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.


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


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


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


• 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



3) Un semplice caso di studio




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







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


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


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







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







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

In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e...

Documents

Transcript of In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e...