In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica UML E NORME IEC Alessandro DE CARLI Anno Accademico 2006-07 In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni

Indice Riflessioni sulle problematiche del software nell’automazione. La norma IEC 61499 Un semplice caso di studio con IEC 61499 Approccio object-oriented Il linguaggio UML Un semplice caso di studio (reprise) 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 GESTIONE SUPERVISIONE COORDINAMENTO CAMPO

Il software nell’automazione (2/4) In tutte le aree applicative informatiche l’automazione non ha bisogno di prestazioni estreme o funzionalità avanzate. Per esempio: Elaborazione: per il controllo di un processo servono moderate capacità di DSP (un processo “veloce” non arriva a più di 2kHz). Un cellulare UMTS de/comprime audio e video in tempo reale. Trasmissione: la banda necessaria è proporzionale alle velocità dei processi (kb/s). Non sono necessarie tecnologie particolari di routing. Le reti a pacchetti moderne con QoS arrivano al gB/s.

Il software nell’automazione (3/4) Visualizzazione: non è sentita la necessità di avere prestazioni/qualità avanzate. Un semplice videogioco fornisce visualizzazione 3D. Alcuni campi applicativi hanno bisogno di precisi studi di HCI (human-computer interface) o HRI (human-robot interface). Conservazione dati: Telecom dagli anni 60 gestisce DB da milioni di utenti il sistema di prenotazione mondiale per le linee aeree fornisce un DB consistente a migliaia di punti vendita.

Il software nell’automazione (4/4) Alcuni requisiti specifici per il software nell’automazione: il tempo di vita del software è più lungo essendo legato a quello dell’impianto  documentabilità e manutenibilità delle soluzioni le competenze informatiche degli utenti sono spesso una parte minore dei loro curricula  complessità tollerabile, standardizzazione un difetto nel software può far perdere tempo e denaro  qualità e affidabilità ...e naturalmente il costo delle soluzioni  tempo di sviluppo

Il futuro dell’automazione (pessimista) Secondo Vyatkins, nel prossimo futuro (5 anni) crescerà la complessità informatica dei componenti industriali Cosa succederà? Aumenterà la potenziale flessibilità delle soluzioni (più linguaggi di programmazione, più formati dei dati, più standard di comunicazione). Le nuove leve tenderanno a trascurare l’ampia eredità nel campo del software per l’automazione. Il risultato sarà una babele di soluzioni che diminuirà l’affidabilità e la qualità dei sistemi. Come garantire la qualità e l’affidabilità del software al crescere della complessità?

L’informatica: un settore particolare L’informatica (computer science) è una scienza giovane (1940-). L’ingegneria informatica (computer/software engineering) e la produzione non-artigianale di software cominciarono nel 1960. L’industria del software esplode successivamente (1980-). Non ci sono state ancora due generazioni di ingegneri; inoltre la creazione del software è sostanzialmente diversa da altre attività ingegneristiche. Le tecnologie informatiche hanno una vita breve paragonabile a quella di un singolo progetto. In Italia il 30-40% dei progetti è abbandonato, è completato in ritardo o fuori budget.

Il costo dei difetti nel software Spesso per il software di uso consumer il costo dei difetti (bug) non viene quantificato. Il 30% dei lavoratori italiani usa il computer. Se ognuno perde 1 ora a settimana (su 40) per i bug, 0.3 / 40 = 0.1% del PIL = 1200mil = 1 miliardo di euro. Questo è un costo nascosto. Però in alcuni casi il costo dei difetti è evidente: L’esempio classico: l’esplosione di un razzo Ariane (1996) dovuto ad un buffer overflow. Automazione di apparecchiature mediche. Nell’industria il costo di un impianto fermo è immediatamente quantificabile.

Informatica: alcuni punti fermi Cosa ci ha lasciato mezzo secolo di informatica riguardo il processo di produzione del software: Gli approcci modulari / con componenti riducono il tempo di sviluppo e la complessità. La standardizzazione dei linguaggi di programmazione, dei formati dei dati e dei linguaggi di modellazione contribuiscono a creare una cultura unica di cui tutti beneficiano. Quando sono utilizzabili, sono utili gli strumenti per: verifica formale del software, progettazione assistita. Norme e strumenti sono inutili senza adeguate metodologie di sviluppo. I temi caldi del momento: il software libero, l’open source, la brevettabilità del software, la brevettabilità delle idee.

L’approccio orientato ai componenti (1/3) Gli informatici invidiano il lavoro degli elettronici. Infatti il progettista elettronico: può progettare un circuito servendosi di un CAD sceglie i componenti discreti/integrati da cataloghi può simulare il comportamento del circuito Quindi a fine giornata l’elettronico è felice: ha riutilizzato il lavoro di altri può verificare formalmente il suo lavoro ciò che ha prodotto è facilmente documentabile e riutilizzabile Mentre l’elettronico torna a casa felice, l’informatico fa le ore piccole per correggere “quell’ultimo bug”.

L’approccio orientato ai componenti (2/3) Un approccio a componenti si basa sul principio DIVIDE ET IMPERA: è più facile risolvere tanti problemi semplici che un unico grande problema complesso. Ma quanto è facile mettere insieme tante piccole soluzioni? Di fatto, la definizione di “componenti informatici” che fornisca pieno riutilizzo / documentabilità / componibilità come i componenti elettronici in generale non ha successo: algoritmi e strutture dati sono complessi. l’interfaccia tra i componenti (formato dei dati) è più complicata. un computer è una macchina sequenziale e il parallelismo deve essere implementato esplicitamente.

L’approccio orientato ai componenti (3/3) Un approccio basato su componenti è l’approccio object-oriented (orientato agli oggetti). Negli anni ‘70-'80 un concetto ormai assodato era la struttura = insieme di dati primitivi Alcuni linguaggi (Ada/Delphi/C++) introdussero il concetto di classe: classe = struttura + algoritmi di manipolazione L’object-oriented programming nasce quindi come tecnologia; diventa successivamente paradigma e si arriva alla visione che sistema = una collezione di oggetti che interagiscono tramite scambio di messaggi

La via verso il successo Come garantire la qualità e l’affidabilità del software per l’automazione al crescere della complessità? linguaggi di programmazione standard 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 Fieldbus IEC 61499, UML IEC 61499 IEC 61499 ??? ???

Indice Riflessioni sulle problematiche del software nell’automazione. La norma IEC 61499 Un semplice caso di studio Approccio object-oriented Il linguaggio UML Un semplice caso di studio (reprise) Conclusioni

I due volti di IEC 61499 I due volti di IEC 61499: IEC 61499 per modellare: “Lo scopo principale di IEC 61499 non è quello di essere una metodologia di programmazione ma di definire in modo formale concetti, modelli e terminologia per descrivere modelli di sistemi distribuiti” IEC 61499 per sviluppare: Vyatkins D’altronde la modellazione è il primo passo necessario per arrivare a strumenti di programmazione. Non si parla ancora di metodologie di sviluppo.

IEC 61499: compromessi del modello Come tutti i modelli, c’è sempre un compromesso tra: generico  dominio particolare semplice  complesso flessibile  rigido informale  formale sintetico  estensivo analisi sintesi  simulazione Per esempio: Schemi elettrici: dominio particolare, semplice, rigido, formale, estensivo, sintesi/simulazione. Diagrammi dei sistemi di controllo: generico, flessibile, informale, sintetico, analisi/sintesi. IEC 61499: generico, semplice, rigido, formale, sintetico, sintesi/simulazione.

IEC 61499: compromessi della norma Cosa influenza la creazione e la fortuna degli standard? Strategie commerciali Politiche (inter)nazionali Un buon tempismo Appoggio accademico Alcuni esempi: I tempi giusti, la snellezza e l’appoggio accademico: ISO/OSI vs. TCP. Lo standard nuoce ai monopolisti: il boicottaggio di Java da parte di Microsoft. L’influenza della politica: l’indecisione europea tra PAL/SECAM/NTSC causa 10 anni di ritardo nell’introduzione della TV a colori in Italia. Lo standard impedisce la segmentazione del mercato: lo strano caso degli alimentatori dei portatili/cellulari.

IEC 61499: compromessi della norma Il mondo è fatto di compromessi: Interessi degli utenti  interessi dei produttori evoluzione rivoluzione punto di arrivo  punto di partenza IEC 61331: interessi degli utenti, evoluzione, punto di arrivo. IEC 61499: evoluzione, punto di partenza.

IEC 61499: Modello funzionale Eventi In entrata Eventi in uscita 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 PIANO INT Nome istanza Associazione dati / eventi RAPPRESENTAZIONE TESTUALE ..........

IEC 61499: Execution Control Chart Evento in entrata Stato iniziale 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 E_IN 1 Transizione istantanea RESPONDING ALGO() E_OUT Stato di computazione Algoritmo Evento In uscita

Esempio: elemento rendez-vous Il componente aspetta E_IN1 e E_IN2 prima di far partire E_OUT. START E_IN1 E_OUT E_IN2 E_IN2 E_IN1 Rendez -vous WAIT_2 1 WAIT_1 E_IN1 E_IN2 FIRE E_OUT

Tipi di blocchi Esistono 3 tipi di blocchi, graficamente simili: Blocchi semplici: comportamento definito da ECC e algoritmi. Blocchi di interfaccia: realizzano interfacciamento con hardware e dispositivi di comunicazione. Blocchi composti: unione di più blocchi (ricorsivamente). E’ incoraggiata la composizione fra blocchi. Da pochi blocchi base è possibile avere comportamenti complessi (la composizione favorisce il riutilizzo e l’eleganza).

I blocchi di interfaccia di servizio I blocchi di interfaccia sono modellati come rispondenti a richieste di servizio. START RESPONDING RSP REQ 1 LEGGI() REQ RSP VALUE Interface BUS/ETHERNET SENSORE E’ modellata similmente l’interfaccia verso le reti e verso i dispositivi fisici.

Modello delle risorse IEC 61499 separa il modello di esecuzione (blocchi, eventi, composizione) dal modello delle risorse che supportano l’esecuzione. L’hardware è diviso in: Risorsa: supporta l’esecuzione di un blocco funzione (es: una scheda, uno dei processori del PC) Dispositivo: può avere più risorse. (es: un PLC con più schede, un PC industriale con più processori) Le applicazioni sono costituite da reti di blocchi che possono essere distribuite su più dispositivi (ma un blocco su una sola risorsa) La norma non è ancora completa per quanto riguarda l’indirizzamento e le modalità di comunicazione di dispositivi diversi.

Indice Riflessioni sulle problematiche del software nell’automazione. La norma IEC 61499 Un semplice caso di studio Approccio object-oriented Il linguaggio UML Un semplice caso di studio (reprise) Conclusioni

Scenario 0 3 0 3 Azionamento Display interno Encoder 4 Freno di 1 2 3 4 0 3 Azionamento Display interno Encoder Freno di sicurezza Bottoni di comando Estensimetro Porte ascensore 0 3 Luce di conferma Bottone di prenotazione

Metodologia di sviluppo Per la particolarità di IEC 61499 sembra coerente una metodologia di sviluppo bottom up – “dal basso in alto” – perché incoraggia l’aggregazione di blocchi semplici in costrutti complessi e riutilizzabili. Sequenza: Definizione dei blocchi di interfaccia. Loop di controllo dell’azionamento. Controllore multiplo. Sequenziamento operazioni. Scheduling (pianificazione del servizio).

Blocchi di interfaccia – Sensori (1/2) I sensori seguono lo schema richiesta/risposta. START RESPONDING RSP REQ 1 LEGGI() REQ RSP VALUE Sensore Nota: per chiarezza sono stati omessi i segnali standard di inizializzazione/spegnimento

Blocchi di interfaccia – Sensori (2/2) Rappresentazione di encoder ed estensimetro. REQ RSP REQ RSP Encoder Estensimetro ALTEZZA PESO

Blocchi di interfaccia – Attuatori SET ALARM COPPIA Azionamento Non siamo interessati ai particolari dell’azionamento. Ipotizziamo che sia comandato in coppia e che abbia un segnale di emergenza. Immaginiamo che il produttore delle porte ci abbia fornito questo blocco. OPEN CLOSE_OK Door CLOSE OPEN_OK

Definizioni blocchi di interfaccia - Bottoni 1 2 3 4 0 3 INIT PRESSED PIANO BottoneA INT ID_ASC 0 3 INIT PRESSED SU/GIU BottoneP PIANO INT BOOL

Blocchi di interfaccia - Display 1 2 3 4 0 3 CHANGE NUMBER Display INT SET ON/OFF Luci BOOL 0 3

Blocco PID Troveremo questo blocco nelle librerie standard. Gli eventi principali configurano i parametri e aggiornano l’uscita. INIT UPDATE UPDATE SET_REF PID KP KI KD … VALUE VALUE REF

Predisposizione Automatica Pid + Autotuning 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: Osservazione del comportamento del sistema da controllare Scelta del modello (semplice: FOPDT,SOPDT) identificazione dei parametri Descrizione del comportamento desiderato ad anello chiuso. Calcolo dei parametri del regolatore: Model-based (metodi di Haalman, Dahlin) Characteristic-based (metodi di Ziegler-Nichols) Ruled-based (soft-computing)

Altri blocchi utili INIT CLOCK T Clock REAL STOP 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. INIT UPDATE OMEGA0 Deriv REAL OMEGA1 VALUE

Semplice loop di controllo INIT CLOCK REQ RSP STOP Clock Encoder T INIT UPDATE UPDATE SET ALARM SET_REF Azionamento PID KP KI KD … VALUE VALUE COPPIA REF

Il loop di controllo incapsulato INIT ALARM STOP UPDATE SET_REF CONTROL LOOP KP KI KD T DERIV ALTEZZA REF

Sequenziamento delle operazioni L’ascensore è al piano. Prenotazione. Chiusura delle porte. Controllo in velocità nel mezzo del percorso. Controllo in posizione per frenatura. Apertura delle porte.

Controllo dell’ascensore – dal di dentro 1 START WAITING E_AL_PIANO E_RICHIESTA CLOSING E_DOOR_CLOSE E_DOOR_CLOSED SPEED E_PID_INIT E_UPDATE & ALTEZZAPIANO POSITION E_PID_INIT E_UPDATE & ALTEZZA=PIANO OPENING E_DOOR_OPEN E_DOOR_OPENED

Sequenziamento SEQUENCE CONTROL E_REQUEST E_REQUEST_OK E_DOOR_CLOSE_OK E_DOOR_OPEN_OK E_DOOR_OPEN E_PID_INIT E_UPDATE SEQUENCE CONTROL PIANO RIF_ALTEZZA ALTEZZA PID_PARAMS

Sequenziamento SEQUENCE CONTROL LOOP CONTROL Door Freno OPEN FRENA E_REQUEST SEQUENCE CONTROL 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 E_SET_REF INIT CONTROL LOOP PID_PARAMS T UPDATE ALTEZZA SET_REF REF ALARM 1ms FRENA Freno OPEN CLOSE_OK Door CLOSE OPEN_OK

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 Molti bottoni di prenotazione Molti ascensori PRESSED BottoneP SU/GIU PIANO Molti bottoni di prenotazione VAI ARRIVATO Ascensore1 PIANO Molti ascensori INIT PRESSED PIANO BottoneA ID_ASC Molti bottoni di comando

Blocco di scheduling L’interfaccia del blocco di scheduling: E_PRENOTAZIONE E_VAI E_COMANDO E_ARRIVATO SCHEDULING PIANO PIANO SU/GIU ID_ASCENSORE ID_ASCENSORE

Riassunto Gerarchia dei function block: SCHEDULING DISPLAY BUTTON ASCENSORE SEQUENCE CONTROL DOOR LOOP CONTROL PID CLOCK AZIONAMENTO ENCODER

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 Riflessioni sulle problematiche del software nell’automazione. La norma IEC 61499 Un semplice caso di studio Approccio object-oriented Il linguaggio UML Un semplice caso di studio (reprise) Confronto 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 Riflessioni sulle problematiche del software nell’automazione. La norma IEC 61499 Un semplice caso di studio Approccio object-oriented Il linguaggio UML Un semplice caso di studio (reprise) Confronto 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 : Si usa UML : 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

UML è approvato dall’OMG Storia dell’UML Lo Unified Modeling Language (UML) è il successore di una serie di metodologie di analisi e progettazione orientate agli oggetti apparse tra la fine degli anni ’80 e i primi anni ’90. UML è approvato dall’OMG Nov ‘97 UML 1.1 IBM, Platinum e altri Set ‘97 UML 1.0 Microsoft, Oracle, HP Gen ‘97 UML 0.9 Jacobson Giu ‘96 Unified Method 0.8 Rumbaugh Booch Ott ‘95

Storia dell’UML UML 2.0 2004 UML 1.5 2003 UML 1.4 2001 L’UML è stato standardizzato dall’OMG, Object Management Group, ed è ora riconosciuto come uno standard OMG. UML 1.4 2001 UML 1.3 1999 UML 1.2 1998 UML 1.5 2003 2004 UML 2.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 comportamentali: 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 avviato da utilizzato da 1..* Riga vendita 0..* descrive Vendita data ora crea_vendita() ha Pagamento importo riferito 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’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 in cassiere cliente 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 oggetto link 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 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 Riflessioni sulle problematiche del software nell’automazione. La norma IEC 614499 Un semplice caso di studio Approccio object-oriented Il linguaggio UML Un semplice caso di studio (reprise) Conclusioni

Sistema di controllo ascensori Consideriamo il sistema modellato precedentemente con IEC 61499 Domande a cui vogliamo rispondere: Quale metodologia adottare per descrivere il sistema secondo UML? Quali diagrammi utilizzare?

Diagramma dei casi d’uso

Diagramma delle classi - Driver

Diagramma delle classi - Generale

Diagramma delle classi – Azionamento Ascensore

Diagramma di sequenza prenotazione Caso d’uso Prenotare Ascensore

Diagramma di sequenza trasporto Caso d’uso Trasporto in Ascensore

Diagramma di sequenza allarme utente Caso d’uso allarme generato da un utente

Diagramma di sequenza allarme interno Caso d’uso allarme interno

Considerazioni finali L’UML è un linguaggio di modellazione universale e in quanto tale può essere utilizzato per qualsiasi tipo di sistema complesso Se utilizzato come strumento di analisi e documentazione di sistemi nel campo dell’automazione industriale permette di: Avere una visione generale del sistema a vari livelli di dettaglio Capire come avvengono nel tempo le interazioni tra i componenti del sistema generale

UML per l’analisi di un sistema di automazione Quali diagrammi utilizzare? Il diagramma dei casi d’uso perché: Definisce il comportamento del sistema (come il sistema agisce e reagisce, come il sistema è visibile all’esterno) Descrive il sistema, l’ambiente e le relazioni tra i due Il diagramma delle classi perché: Fornisce una descrizione statica del sistema e delle relazioni tra le classi (associazione,aggregazione e composizione) Visione generale del sistema I diagrammi di sequenza perché: Descrivono l’interazione temporale dei componenti di un sistema Permettono di individuare facilmente le sequenze di messaggi scambiati dagli elementi del sistema

Indice Riflessioni sulle problematiche del software nell’automazione. La norma IEC 61499 Un semplice caso di studio Approccio object-oriented Il linguaggio UML Un semplice caso di studio (reprise) 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à?