La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

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

Presentazioni simili


Presentazione sul tema: "In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07."— Transcript della presentazione:

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

2 Indice 1)Riflessioni sulle problematiche del software nellautomazione. 2)La norma IEC )Un semplice caso di studio con IEC )Approccio object-oriented 5)Il linguaggio UML 6)Un semplice caso di studio (reprise) 7)Conclusioni

3 Il software nellautomazione (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

4 Il software nellautomazione (2/4) In tutte le aree applicative informatiche lautomazione 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.

5 Il software nellautomazione (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.

6 Il software nellautomazione (4/4) Alcuni requisiti specifici per il software nellautomazione: il tempo di vita del software è più lungo essendo legato a quello dellimpianto 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

7 Il futuro dellautomazione (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 lampia eredità nel campo del software per lautomazione. –Il risultato sarà una babele di soluzioni che diminuirà laffidabilità e la qualità dei sistemi. Come garantire la qualità e laffidabilità del software al crescere della complessità?

8 Linformatica: un settore particolare Linformatica (computer science) è una scienza giovane (1940-). Lingegneria informatica (computer/software engineering) e la produzione non-artigianale di software cominciarono nel Lindustria 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.

9 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: –Lesempio classico: lesplosione di un razzo Ariane (1996) dovuto ad un buffer overflow. – Automazione di apparecchiature mediche. –Nellindustria il costo di un impianto fermo è immediatamente quantificabile.

10 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, lopen source, la brevettabilità del software, la brevettabilità delle idee.

11 Lapproccio 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 lelettronico è felice: –ha riutilizzato il lavoro di altri –può verificare formalmente il suo lavoro –ciò che ha prodotto è facilmente documentabile e riutilizzabile Mentre lelettronico torna a casa felice, linformatico fa le ore piccole per correggere quellultimo bug.

12 Lapproccio 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. –linterfaccia tra i componenti (formato dei dati) è più complicata. –un computer è una macchina sequenziale e il parallelismo deve essere implementato esplicitamente.

13 Lapproccio orientato ai componenti (3/3) Un approccio basato su componenti è lapproccio 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 Lobject-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

14 La via verso il successo Come garantire la qualità e laffidabilità del software per lautomazione 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 Fieldbus ???

15 Indice 1)Riflessioni sulle problematiche del software nellautomazione. 2)La norma IEC )Un semplice caso di studio 4)Approccio object-oriented 5)Il linguaggio UML 6)Un semplice caso di studio (reprise) 7)Conclusioni

16 I due volti di IEC I due volti di IEC 61499: –IEC per modellare: Lo scopo principale di IEC 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 per sviluppare: Vyatkins Daltronde la modellazione è il primo passo necessario per arrivare a strumenti di programmazione. Non si parla ancora di metodologie di sviluppo.

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

18 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 lappoggio accademico: ISO/OSI vs. TCP. –Lo standard nuoce ai monopolisti: il boicottaggio di Java da parte di Microsoft. –Linfluenza della politica: lindecisione europea tra PAL/SECAM/NTSC causa 10 anni di ritardo nellintroduzione della TV a colori in Italia. –Lo standard impedisce la segmentazione del mercato: lo strano caso degli alimentatori dei portatili/cellulari.

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

20 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. INITPRESSED BottoneA PIANO INT Eventi In entrata Eventi in uscita Associazione dati / eventi Nome istanza RAPPRESENTAZIONE TESTUALE

21 IEC 61499: Execution Control Chart Il comportamento interno è descritto dallExecution Control Chart (diagramma del controllo dellesecuzione). 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 in entrata Evento In uscita Stato di computazione Algoritmo Transizione istantanea

22 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

23 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 leleganza).

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

25 Modello delle risorse IEC separa il modello di esecuzione (blocchi, eventi, composizione) dal modello delle risorse che supportano lesecuzione. Lhardware è diviso in: –Risorsa: supporta lesecuzione 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 lindirizzamento e le modalità di comunicazione di dispositivi diversi.

26 Indice 1)Riflessioni sulle problematiche del software nellautomazione. 2)La norma IEC )Un semplice caso di studio 4)Approccio object-oriented 5)Il linguaggio UML 6)Un semplice caso di studio (reprise) 7)Conclusioni

27 Scenario Bottone di prenotazione Luce di conferma Bottoni di comando Display interno Azionamento Encoder Freno di sicurezza Estensimetro Porte ascensore

28 Metodologia di sviluppo Per la particolarità di IEC sembra coerente una metodologia di sviluppo bottom up – dal basso in alto – perché incoraggia laggregazione di blocchi semplici in costrutti complessi e riutilizzabili. Sequenza: 1.Definizione dei blocchi di interfaccia. 2.Loop di controllo dellazionamento. 3.Controllore multiplo. 4.Sequenziamento operazioni. 5.Scheduling (pianificazione del servizio).

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

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

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

32 Definizioni blocchi di interfaccia - Bottoni INITPRESSED SU/GIU BottoneP SU/GIU PIANO INT BOOL INITPRESSED PIANO BottoneA PIANO INT ID_ASC

33 Blocchi di interfaccia - Display CHANGE NUMBER Display INT SET ON/OFF Luci BOOL

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

35 Predisposizione Automatica Nelle librerie saranno presenti anche blocchi per lauto/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

36 Altri blocchi utili INIT CLOCK T Clock REAL STOP INIT UPDATE OMEGA0 Deriv REAL UPDATE OMEGA1 REAL VALUE Questo blocco innesca la catena di eventi che porta al calcolo e laggiornamento delle uscite. Esempio di un blocco che calcola la derivata in banda di un segnale.

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

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

39 Sequenziamento delle operazioni Sequenziamento delle operazioni. 1.Lascensore è 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.

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

41 Sequenziamento 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

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

43 Controllo e sequenziamento Questo blocco incapsula tutto quello che abbiamo progettato finora: controllo e sequenziamento. VAI ARRIVATO Ascensore PIANO

44 Problemi di pianificazione del servizio 0 3

45 Blocco di scheduling SCHEDULING PRESSED BottoneP SU/GIU PIANO PRESSED BottoneP SU/GIU PIANO PRESSED BottoneP SU/GIU PIANO Molti bottoni di prenotazione INITPRESSED PIANO BottoneA PIANO ID_ASC INITPRESSED PIANO BottoneA PIANO ID_ASC INITPRESSED PIANO BottoneA PIANO ID_ASC Molti bottoni di comando VAI ARRIVATO Ascensore1 PIANO VAI ARRIVATO Ascensore1 PIANO VAI ARRIVATO Ascensore1 PIANO Molti ascensori

46 Blocco di scheduling Linterfaccia del blocco di scheduling: E_ARRIVATO SCHEDULING E_PRENOTAZIONE PIANO E_COMANDO PIANO E_VAI SU/GIU ID_ASCENSORE

47 Riassunto PIDCLOCKAZIONAMENTOENCODER SEQUENCE CONTROL DOOR DISPLAY BUTTON DISPLAYBUTTON ASCENSORE LOOP CONTROL SCHEDULING Gerarchia dei function block:

48 Evoluzione da IEC Anche nello standard precedente esistevano i function block ma molti sono i cambiamenti dallo standard precedente: Tramite gli eventi, nei diagrammi è stabilito lordine di esecuzione; non cè il problema dei loop. Non sono permesse variabili globali; ogni blocco comunica con lesterno solo tramite eventi/dati. Non cera unarchitettura standard per distribuire i blocchi.

49 Un futuro felice Il futuro con IEC 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).

50 Indice 1)Riflessioni sulle problematiche del software nellautomazione. 2)La norma IEC )Un semplice caso di studio 4)Approccio object-oriented 5)Il linguaggio UML 6)Un semplice caso di studio (reprise) 7)Confronto 8)Conclusioni

51 Progettazione object oriented La progettazione software può essere rappresentata come un insieme di oggetti che interagiscono Parole chiave nellapproccio OO: –Classe Denota le caratteristiche comuni di entità che hanno uno stato e un insieme di operazioni Un oggetto è unistanza 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

52 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 loggetto istanziato può fornire –Rappresenta ciò che loggetto sa fare nello scenario applicativo, le sue responsabilità Livello interno o privato –Definisce le proprietà delloggetto (i dati) e le modalità di trattamento di questi dati (i metodi)

53 Information hiding Normalmente gli oggetti nascondono la loro struttura allambiente circostante –Esempio: una macchinetta per il caffè da ufficio. Se cambia limplementazione 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à duso. –Effetti benefici sulla manutenzione del software: è possibile apportare variazioni alloggetto in modo trasparente per le applicazioni che lo usano.

54 Sviluppo orientato agli oggetti Lanalisi, la progettazione e la programmazione object-oriented sono legate ma distinte: –OOA (o.-o. analysis) riguarda lanalisi 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.)

55 Indice 1)Riflessioni sulle problematiche del software nellautomazione. 2)La norma IEC )Un semplice caso di studio 4)Approccio object-oriented 5)Il linguaggio UML 6)Un semplice caso di studio (reprise) 7)Confronto 8)Conclusioni

56 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!

57 Che cosè lUML? LUML è 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 LUML 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

58 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

59 Storia dellUML UML è approvato dallOMG Nov 97 UML 1.1 IBM, Platinum e altri e altri Set 97 UML 1.0 Microsoft, Oracle, HP e altri Gen 97 UML 0.9 Jacobson Giu 96 Unified Method 0.8 RumbaughBooch Ott 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.

60 Storia dellUML LUML è stato standardizzato dallOMG, Object Management Group, ed è ora riconosciuto come uno standard OMG. UML UML UML UML UML 2.0 versione attuale

61 Contributi allUML

62 UML e meta-modello LUML nella sua incarnazione attuale definisce una notazione e un meta-modello La notazione è laspetto 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 unicona che li rappresenta graficamente Gli elementi del meta-modello possono comparire in diagrammi di diverso tipo Le regole permettono verifiche di correttezza

63 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à.

64 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

65 Come viene utilizzato UML UML come abbozzo (sketch) UML come progetto dettagliato (blueprint) UML come linguaggio di programmazione

66 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 ( lassenza di qualcosa non significa che non esista) –Espressività Diagrammi intesi come figure I diagrammi sono spesso creati rapidamente e in modo collaborativo (lavagna)

67 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 dellIngegneria 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

68 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

69 MDA vs. Round trip engineering MDA (Model Driven Architecture): –è unarchitettura per la generazione automatica di codice, definita e gestita dallOMG –Idealmente, con lutilizzo 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

70 Benefici portati dallUML 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

71 Benefici portati dallUML 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

72 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

73 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 duso –Diagramma di stato –Diagramma delle attività –Diagramma di sequenza –Diagramma di comunicazione –Diagramma dei tempi –Diagramma di sintesi dellinterazione

74 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 loggetto appartiene

75 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 uninterfaccia –Ereditarietà : è una relazione in cui una classe figlia può ereditare gli attributi e le operazioni da una classe più generica detta classe padre

76 Diagramma delle classi esempio Amministratore Cassiere Negozio nome indirizzo Prodotto POST * 1 * 1 avviato da 1111 utilizzato da 1..* 1 1 Riga vendita 0..* 1 1 descrive Vendita data ora crea_vendita() 11 * 1..*1 1 ha Pagamento importo 11 1 riferito a Pag. Contanti Pag. Carta Credito associazione aggregazione specializzazione / generalizzazione

77 Diagramma dei casi duso Mostra: –le modalità di utilizzo del sistema (casi duso) –gli attori del sistema –le relazioni tra attori e casi duso Scenario : sequenza di passi che descrivono linterazione tra un utente e il sistema caso dusoUn caso duso –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)

78 Diagramma dei casi duso acquistare articoli log in cassiere cliente rimborsare articoli venduti attore: un utilizzatore del sistema caso d'uso: un "modo" di utilizzare il sistema

79 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 duso è realizzato tramite la collaborazione di un insieme di oggetti

80 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

81 Diagrammi di collaborazione Eun diagramma di interazione: rappresenta un insieme di oggetti che collaborano per realizzare il comportamento di uno scenario di un caso duso 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)

82 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)

83 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 allaltro, 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

84 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

85 Uso dei diagrammi UML DEFINIZIONE DELLE ATTIVITA: attraverso colloqui con lutilizzatore 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 dellanalisi allutilizzatore COMPRENSIONE DELLUTILIZZO DEL SISTEMA : attraverso colloqui con i potenziali utenti vengono definiti gli attori e i relativi casi duso, per realizzare un diagramma dei casi duso

86 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 DELLINTEGRAZIONE DEL SISTEMA CON SISTEMI PREESISTENTI : si sviluppa un diagramma di distribuzione per definire lintegrazione con i sistemi preesistenti o con altri sistemi con i quali è necessario cooperare DEFINIZIONE DEGLI OGGETTI : dallanalisi 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

87 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 DELLINTERFACCIA UTENTE E COLLEGAMENTO AL CODICE : una volta che è a disposizione il sistema funzionante e completo con linterfaccia utente INSTALLAZIONE DEL SISTEMA COMPLETO SULLHARDWARE APPROPRIATO PROVE SUL SISTEMA INSTALLATO

88 Indice 1)Riflessioni sulle problematiche del software nellautomazione. 2)La norma IEC )Un semplice caso di studio 4)Approccio object-oriented 5)Il linguaggio UML 6)Un semplice caso di studio (reprise) 7)Conclusioni

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

90 Diagramma dei casi duso

91 Diagramma delle classi - Driver

92 Diagramma delle classi - Generale

93 Diagramma delle classi – Azionamento Ascensore

94 Diagramma di sequenza prenotazione Caso duso Prenotare Ascensore

95 Diagramma di sequenza trasporto Caso duso Trasporto in Ascensore

96 Diagramma di sequenza allarme utente Caso duso allarme generato da un utente

97 Diagramma di sequenza allarme interno Caso duso allarme interno

98 Considerazioni finali LUML è 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 dellautomazione 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

99 UML per lanalisi di un sistema di automazione Quali diagrammi utilizzare? –Il diagramma dei casi duso perché: Definisce il comportamento del sistema (come il sistema agisce e reagisce, come il sistema è visibile allesterno) Descrive il sistema, lambiente 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 linterazione temporale dei componenti di un sistema Permettono di individuare facilmente le sequenze di messaggi scambiati dagli elementi del sistema

100 Indice 1)Riflessioni sulle problematiche del software nellautomazione. 2)La norma IEC )Un semplice caso di studio 4)Approccio object-oriented 5)Il linguaggio UML 6)Un semplice caso di studio (reprise) 7)Conclusioni

101 IEC vs. UML La norma IEC e lUML permettono di affrontare un problema di automazione seguendo due approcci complementari. Nellesempio sviluppato la semplicità dellapplicazione rendeva più immediato lutilizzo dei function block. Comunque, anche tentando una soluzione di tipo bottom-up, non si può prescindere da una visione dinsieme che UML può fornire nel giusto livello di dettaglio. Infatti IEC non sembra scalabile con la complessità, i progetti più complessi sembrano un groviglio di blocchi e fili.

102 Diceva luomo con la clava: devo fare la guerra, non ho tempo per conoscere le nuove tecnologie …e morì incenerito da un missile! Lavvento di nuovi standard e nuovi strumenti non deve essere inteso come ciò che si può anche non conoscere… le cose funzioneranno lo stesso! LAutomazione 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à?


Scaricare ppt "In collaborazione con Andrea Censi, Massimo Ferri e Luca Marchionni Dipartimento di Informatica e Sistemistica Alessandro DE CARLI Anno Accademico 2006-07."

Presentazioni simili


Annunci Google