PROGRAMMA DI AUTOMAZIONE 2

Slides:



Advertisements
Presentazioni simili
Informatica II – Basi di Dati (08/09) – Parte 1
Advertisements

Dipartimento di Ingegneria Idraulica e Ambientale - Universita di Pavia 1 Caduta non guidata di un corpo rettangolare in un serbatoio Velocità e rotazione.
1 MeDeC - Centro Demoscopico Metropolitano Provincia di Bologna - per Valutazione su alcuni servizi erogati nel.
OBBLIGO SCOLASTICO ASSI CULTURALI.
La progettazione secondo la norma internazionale ISO 9001
Analisi e progettazione
LA PIATTAFORMA FAD FORTECHANCE
La rete tra imprese è una forma organizzativa basata su due principi :
Le tecnologie informatiche per l'azienda
Frontespizio Economia Monetaria Anno Accademico
AMBIENTE CONTESTO NEL QUALE UN’ORGANIZZAZIONE OPERA, COMPRENDENTE L’ARIA, L’ACQUA, IL TERRENO, LE RISORSE NATURALI, LA FLORA, LA FAUNA, GLI ESSERI UMANI.
Lez. 3 - Gli Indici di VARIABILITA’
IL PROCESSO DI REVISIONE AZIENDALE
1 14. Verifica e Validazione Come assicurarsi che il software corrisponda alle necessità dellutente? Introdurremo i concetti di verifica e validazione.
L’Activity Based Management
Obiettivi del corso di Statistica Medica.
La Tecnica NTG 5 PERFORMANCE Metodologia. La Tecnica NTG 5 Performance OBIETTIVI razionalizzare le modalità per raggiungere i risultati stimolare la quantificazione.
Canale A. Prof.Ciapetti AA2003/04
Corso di Informatica (Programmazione)
Corso di Informatica per Giurisprudenza Lezione 5
Area: la gestione dei progetti complessi
L'alternanza scuola - lavoro.
Master universitario di II livello in Ingegneria delle Infrastrutture e dei Sistemi Ferroviari Anno Accademico 2012/2013 Cultura dimpresa, valutazione.
1Milano, 3 Novembre 2004Assemblea Nazionale FISM WORKSHOP La certificazione dei requisiti di qualità per le Società Medico-Scientifiche Presentazione del.
Cos’è un problema?.
FONDAMENTI DI INFORMATICA III A2A2-1 CARATTERISTICHE E MODELLIZZAZIONE DEL LAVORO DUFFICIO Argomento 2 Approfondimento 2 CARATTERISTICHE E MODELLIZZAZIONE.
PIANO NAZIONALE DI AGGIORNAMENTO COMPETENZE COMUNI DELLA FIGURA PROFESSIONALE DEL DOMANI PER UN TURISMO DI QUALITA CASERTA APRILE 2001.
Il marketing: costruire una relazione profittevole con il cliente
Modello E-R Generalizzazioni
Il modello delle ISO 9000 per il miglioramento dei servizi Il caso Comune di Ravenna : Lapplicazione del modello delle ISO 9000 ai Lavori Pubblici Ravenna,
XIV Convegno Organizzativo AVIS Provinciale Guiglia, Sabato 4 Dicembre 2010 Le prospettive della raccolta del sangue in Provincia di Modena Esiti dei questionari.
Questionari sulla didattica: le risposte di studenti & docenti.
La struttura organizzativa e informativa del controllo
CHARGE PUMP Principio di Funzionamento
La progettazione di un sistema informatico
Q UESTIONI ETICHE E BIOETICHE DELLA DIFESA DELLA VITA NELL AGIRE SANITARIO 1 Casa di Cura Villa San Giuseppe Ascoli Piceno 12 e 13 dicembre 2011.
ISTITUTO COMPRENSIVO TORREGROTTA REPORT DATI QUESTIONARIO Alunni Scuola Primaria Classe V A.S.2012/2013.
ORDINE DI CHIAMATA a 1minuto e 2 minuti PRINCIPALI TEMPI DELLA COMPETIZIONE ORDINE DI CHIAMATA a 1minuto e 2 minuti PRINCIPALI TEMPI DELLA COMPETIZIONE.
L’ingegneria del software
LA QUALITA’ NELLA PROGRAMMAZIONE DELL’ESERCIZIO
Il processo di sviluppo del Sw: strategia make
ISTITUTO COMPRENSIVO “G. BATTAGLINI” MARTINA FRANCA (TA)
Dipartimento di Informatica e Sistemistica
Dipartimento di Informatica e Sistemistica
Dipartimento di Informatica e Sistemistica
Lo sviluppo del progetto informatico
A cosa serve GWAESSE? E’ un software di semplice utilizzo per la configurazione e la preventivazione di quadri AS (per moli e campeggi), ASC (per cantiere)
Un trucchetto di Moltiplicazione per il calcolo mentale
1 Ly-LAB Sistema di gestione dei dati analitici di laboratorio.
Prima rilevazione sullo stato di attuazione della riforma degli ordinamenti nelle istituzioni scolastiche in LOMBARDIA Attuazione del D.L. 59/2003 a.s.
Strumenti operativi Si tratta di strumenti la cui finalità è quella di migliorare l’organizzazione dell’assistenza e, di conseguenza, favorire l’erogazione.
Esempi risolti mediante immagini (e con excel)
Analisi dei Requisiti (Requirements Engineering) Seminario RE Università degli Studi di Padova, 12 Gennaio 2004.
Atzeni, Ceri, Paraboschi, Torlone Basi di dati McGraw-Hill,
1 ORGAMIZZAZIONE E GESTIONE DELLE RISORSE UMANE. 2 PRESENTAZIONE DEL CORSO L’Organizzazione aziendale La gestione delle persone.
Scelta di un modello di processo: esempio
Commenti alle Attività Generiche. Attività Generiche (Pressman) Principali: Comunicazioni; Pianificazione; Modellazione; Costruzione, Dispiegamento Collaterali:
Esercitazioni di Ingegneria del Software con UML
LA DIMENSIONE IMMATERIALE DEL CONTROLLO
A.P. cat. B - 1 Per chi vuole: Libro di testo D.P. Curtis, K. Foley, K. Sen, C. Morin Informatica di base 2° edizione Mc Graw-Hill Companies.
Controllo di gestione, strumenti di pianificazione
Diagramma delle Classi
Sistemi di Gestione per la Qualità
Fondamenti di Informatica 2 Ingegneria Informatica Docente: Giovanni Macchia a.a
Progettazione di una base di dati Ciclo di vita di un sistema informativo Studio di fattibilità definisce le varie alternative possibili, i relativi costi.
Master MATITCiclo di vita del Sistema Informativo1 CICLO DI VITA DEL SISTEMA INFORMATIVO.
Progettazione di basi di dati: metodologie e modelli
Standard e strumenti per lo sviluppo del software Marco Carezzano Andrea Andrenacci (ZEROPIU, Business Partner di Telecom Italia) Milano, 2 febbraio 2005.
Le basi di dati.
L’analisi dell’esperienza: alcuni concetti chiave Competenze emergenti e occupazione nel turismo A.A
Transcript della presentazione:

PROGRAMMA DI AUTOMAZIONE 2 PROGETTAZIONE DI UN SISTEMA COMPLESSO PROGRAMMA DI AUTOMAZIONE 2 APPROCCI ALLA PROGETTAZIONE DI UN SISTEMA CONTROLLATO COMPLESSO MOVIMENTAZIONE CONTROLLATA ELEMENTI DI CINEMATICA MOTORE ELETTRICI PER LA MIVIMENTAZIONE CONTROLLATA MOTORI A CORRENTE CONTINUA MOTORI A CORRENTE ALTERNATA AZIONAMENTI CON MOTORE ASINCRONO AZIONAMENTI CON MOTORE BRUSHLESS MOTORI A PASSO AZIONAMENTI MULTIASSE MODALITÀ DI CONTROLLO INNOVATIVE MECCATRONICA APPROCCIO OBJECT ORIENTED LINGUAGGI OBJECT ORIENTED IL LINGUAGGIO UML UML E NORME IEC PROGRAMMA DEL CORSO 1

Dipartimento di Informatica e Sistemistica Procedure di Progettazione e di Documentazione per il Controllo di Sistemi Complessi Alessandro DE CARLI Anno Accademico 2006-07 In collaborazione con Eleonora LUCIANI, Andrea FIASCHETTI, Stefano ANDREOZZI

Apri la mente a quel ch' io ti paleso PROGETTAZIONE DI UN SISTEMA COMPLESSO Apri la mente a quel ch' io ti paleso e fermalvi entro; ché non fa scienza, sanza lo ritenere, avere inteso. Due cose si convegnono a l' essenza di questo sacrificio: l' una è quella di che si fa; l' altr' è la convenenza. Paradiso, CANTO 5, 41-45 REMINISCENZE LETTERARIE 3

ORGANIZZAZIONE DEL LAVORO PROGETTAZIONE DI UN SISTEMA COMPLESSO ORGANIZZAZIONE DEL LAVORO Tradizionale Innovativa FONDAMENTA VALORE DI BENI MATERIALI ED IMMATERIALI VALORE DI BENI MATERIALI QUALITÀ DEI SERVIZI TECNOLOGIE CONVENZIONALI BASATE SULLA MECCANICA, L’ELETTROTECNICA, ……… TECNOLOGIE INNOVATIVE CONCENTRATE SULL’INFORMATICA CAPITALE GRUPPI FINANZIARI ISTITUZIONALIZZATI DIPENDENTI INVESTIMENTI COMPETENZE E PROFESSIONALITÀ DEI DIPENDENTI RENDIMENTO DI CAPITALI A PRESTITO NUOVE PROSPETTIVE OCCUPAZIONALI 4

PROGETTAZIONE DI UN SISTEMA COMPLESSO REDDITIVITÀ BASSA PERCHÉ COLLEGATA AL VALORE DEI BENI MATERIALI ELEVATA PERCHÉ COLLEGATA AL VALORE AGGIUNTO CONOSCENZE IN CONTINUA EVOLUZIONE CONSOLIDATE BASATE SUL CONTINUO AGGIORNAMENTO BASATE SUL RICORDO BASATE SULL’UTILIZZAZIONE ISTITUZIONALIZZATE REALIZZAZIONI APERTE ALL’INNOVAZIONE SOSTANZIALMENTE CONSERVATIVE MIGLIORAMENTI MARGINALI ORIENTATE AL CAMBIAMENTO NUOVE PROSPETTIVE OCCUPAZIONALI 5

NUOVE PROSPETTIVE OCCUPAZIONALI PROGETTAZIONE DI UN SISTEMA COMPLESSO Organizzazione Tradizionale per GRUPPI Organizzazione Innovativa per COMPETENZE CRISTALLIZZATA IN VIA DI EVOLUZIONE SUDDIVISIONE DEL LAVORO IN GRUPPI COORDINATI ASSEGNAZIONE INDIVIDUALE DEL LAVORO CONOSCENZE DI BASE COMUNI E COMPETENZE SPECIFICHE DIVERSIFICATE COMPETENZE INDIVIDUALI DIVERSIFICATE FIDUCIA RECIPROCA VERIFICATA CONTINUAMENTE SUL CAMPO FIDUCIA RECIPROCA ASSOLUTA MA NON VERIFICATA MEMORIA DISTRIBUITA IN CONTINUO AGGIORNAMENTO MEMORIA COLLETTIVA TACITA E RADICATA DOMINIO DI CONOSCENZE IN CONTINUA EVOLUZIONE DOMINIO DI CONOSCENZE RIGIDO NUOVE PROSPETTIVE OCCUPAZIONALI 6

LE FASI DELL’APPRENDIMENTO PROGETTAZIONE DI UN SISTEMA COMPLESSO LE FASI DELL’APPRENDIMENTO CONOSCENZA COMPRENSIONE CAPACITÀ DI APPLICARE CAPACITÀ DI ANALISI CAPACITÀ DI SINTESI CAPACITÀ DI VALUTARE APPRENDIMENTO 7

GESTIONE DEL PROGETTO PROGETTAZIONE DI UN SISTEMA COMPLESSO COORDINAMENTO DEI RISULTATI SUDDIVISIONE DELLE COMPETENZA DA PARTE DEI MEMBRI DEL GRUPPO APPRENDIMENTO DELLA BASE DI CONOSCENZE DA PARTE DEL GRUPPO RICERCA E SELEZIONE DELLE PERSONE CHE FORMANO IL GRUPPO DI PROGETTAZIONE RICERCA E SELEZIONE DELLE INFORMAZIONI PROGETTAZIONE DI UN SISTEMA COMPLESSO 8

IMPATTO DELLA NUOVA ORGANIZZAZIONE DELL’ECONOMIA E DELLE COMPETENZE PROGETTAZIONE DI UN SISTEMA COMPLESSO IMPATTO DELLA NUOVA ORGANIZZAZIONE DELL’ECONOMIA E DELLE COMPETENZE IN ITALIA NON SONO DIFFUSE E ISTITUZIONALIZZATE: IL MERCATO FINANZIARIO INGLESE. L’ AMPIEZZA INDUSTRIALE TEDESCA. LE BASI TECNOLOGICHE FRANCESI. LA CULTURA INFORMATICA SCANDINAVA. LA FLESSIBILITÀ DI LAVORO OLANDESE. L’IMPRENDITORIALITÀ STATUNITENSE. LA CAPACITÀ DI REALIZZAZIONE INNOVATIVA GIAPPONESE. LA CAPACITÀ DI RIPRODURRE, REALIZZARE E COMMERCIALIZZARE PRODOTTI INNOVATIVI DEI CINESI. IL SISTEMA UNIVERSITARIO E QUELLO PRODUTTIVO SONO ANCORA TRA I PIÙ ARRETRATI E QUELLO AMMINISTRATIVO E LEGISLATIVO TRA I PIÙ RIGIDI. MOLTO È LASCIATO ALLA RESPONSABILITÀ DI ALCUNI DOCENTI, DI ALCUNI IMPRENDITORI NONCHÉ ALLA INIZIATIVA DEI DISCENTI!!! IMPATTO DELLA NUOVA ORGANIZZAZIONE 9

Richieste dei “cacciatori di teste” PROGETTAZIONE DI UN SISTEMA COMPLESSO Richieste dei “cacciatori di teste” Corretto impiego della lingua italiana e padronanza dell’inglese parlato e scritto Buona presenza Dinamismo Spirito di iniziativa e di sacrificio Interessi collaterali ed esperienze all’estero Predisposizione ai contatti umani Determinazione e serietà Conoscenza degli strumenti informatici più in uso (pacchetto office, internet, ecc.) Solida formazione nelle materie di base dell’ingegneria Padronanza di un settore specifico FORMAZIONE CULTURALE DELL’ESPERTO 10

PROGETTAZIONE NB: PROGETTAZIONE DI UN SISTEMA COMPLESSO DEFINIZIONE: Impegno temporaneo intrapreso allo scopo di creare un prodotto, un servizio o un risultato. “TEMPORANEO” SIGNIFICA CHE HA UN INIZIO E UNA FINE. LA FINE SI RAGGIUNGE QUANDO VENGONO OTTENUTI GLI OBIETTIVI PREPOSTI, OPPURE QUANDO È EVIDENTE CHE SARÀ IMPOSSIBILE RAGGIUNGERLI OVVERO QUANDO IL PROGETTO NON È PIÙ NECESSARIO O VIENE CHIUSO. - NON SIGNIFICA DI BREVE DURATA - NON E’ UN’ATTIVITA’ RIPETITIVA E CICLICA NB: IL RISULTATO DI UN PROGETTO DEVE ESSERE UN PRODOTTO MISURABILE E VERIFICABILE. FORMAZIONE CULTURALE DELL’ESPERTO 11

VERIFICA DELLE FINALITÀ DESIDERARE E ACCETTAZIONE DELLE PRESTAZIONI PROGETTAZIONE DI UN SISTEMA COMPLESSO APPROCCIO CONVENZIONALE alle nuove realizzazioni COMMITTENTE FINALITÀ DESIDERATE PROGETTAZIONE REALIZZAZIONE DEL PROGETTO COSTO ELEVATO MESSA IN ESERCIZIO VERIFICA DELLE FINALITÀ DESIDERARE E ACCETTAZIONE DELLE PRESTAZIONI MODIFICHE APPROCCIO CONVENZIONALE 12

REALIZZAZIONE DEL PROGETTO IN REALTÀ VIRTUALE PROGETTAZIONE DI UN SISTEMA COMPLESSO APPROCCIO INNOVATIVO alle nuove realizzazioni FUNZIONALITÀ COMMITTENTE PRESTAZIONI PROGETTAZIONE COSTO BASSO REALIZZAZIONE DEL PROGETTO IN REALTÀ VIRTUALE VERIFICA DELLA FUNZIONALITÀ E DELLE PRESTAZIONI MODIFICHE ESSENZIALI REALIZZAZIONE DEL PROGETTO MODIFICATO COSTO LIMITATO MESSA IN ESERCIZIO VALIDAZIONE DELLA FUNZIONALITÀ E DELLE PRESTAZIONI MODIFICHE MARGINALI APPROCCIO INNOVATIVO 13

Voglio guadagnare tantissimo e subito!!! Voglio essere soddisfatto!! PROGETTAZIONE DI UN SISTEMA COMPLESSO Approccio ad una NUOVA REALIZZAZIONE RICHIESTE DEL COMMITTENTE DAMMI Quello che ti chiedo!! Subito!! Al costo minimo!! VOGLIO una soluzione non sperimentale innovativa esclusiva facile da usare di elevata qualità Voglio guadagnare tantissimo e subito!!! Voglio essere soddisfatto!! RICHIESTE DELL’UTENTE FINALE 14

- tendenza ad affidarsi a metodologie empiriche e regole non scritte; PROGETTAZIONE DI UN SISTEMA COMPLESSO ATTUALMENTE IN MOLTE APPLICAZIONI L’INGEGNERE È CHIAMATO A CONDIVIDERE CON SPECIALISTI DI ALTRI SETTORI I PROBLEMI DI: connessione di sistemi realizzati con tecnologie eterogenee per portare a compimento l’obbiettivo prefissato comportamento del sistema complessivo differente da quello previsto e desiderato anche se ogni singolo sottosistema è stato realizzato correttamente. incremento in quantità e gravità dei problemi di progettazione e di realizzazione all’aumentare della complessità del sistema. Nella maggioranza dei casi tali problemi sono aggravati da: - difficoltà nel definire e specificare le funzionalità richieste; - tendenza ad affidarsi a metodologie empiriche e regole non scritte; - progettazione di insieme orientata a mitigare l’effetto di potenziali pericoli determinati da errori concettuali e procedurali nella progettazione dei singoli componenti. PROBLEMI SALIENTI DELLA PROGETTAZIONE 15

L’attività di progettazione deve essere definita rigorosamente: PROGETTAZIONE DI UN SISTEMA COMPLESSO aumento della complessità nella progettazione. metodologia che favorisca il riutilizzo e l’individuazione degli errori nelle prime fasi del progetto L’attività di progettazione deve essere definita rigorosamente: - chiaramente comprensibile - sottoposta a verifica di validità durante lo svolgimento condivisione dei componenti e verifiche di progetto prima della realizzazione di prototipi. ATTUALE SCENARIO 16

BASSO LIVELLO ASTRAZIONE ALTO LIVELLO ASTRAZIONE PROGETTAZIONE DI UN SISTEMA COMPLESSO BASSO LIVELLO ASTRAZIONE ALTO LIVELLO ASTRAZIONE RIUTILIZZAZIONE PIÙ EFFICACE PER LA RIDUZIONE DEI COSTI E DEL TEMPO DI SVILUPPO DI UNA REALIZZAZIONE POCHISSIME DIFFERENZE FRA I VARI ASPETTI DELLA PROGETTAZIONE MINIME VARIAZIONI NELLE SPECIFI-CHE POSSONO PORTARE AD IMPLE-MENTAZIONI MOLTO DIFFERENZIATE PUÒ ESSERE CONDIVISA SOLO UNA MINIMA PARTE DEL LAVORO NECES-SARIO AD OTTENERE L’IMPLEMEN-TAZIONE FINALE L’OBIETTIVO FINALE PUÒ ESSERE QUELLO DI CREARE UNA LIBRERIA DI FUNZIONI (CIASCUNA DELLE QUALI ASSOCIATA ALLA PROPRIA IMPLEMENTAZIONE HARDWARE E SOFTWARE) CHE POSSA ESSERE UTILIZZATA PER TUTTI I NUOVI PROGETTI. ASTRAZIONE: PRO E CONTRO 17

SCIENZE DI BASE DELL’INGEGNERIA PROGETTAZIONE DI UN SISTEMA COMPLESSO FORMAZIONE CULTURALE IN AUTOMAZIONE INDUSTRIALE DI UN PROGETTISTA AUTOMAZIONE INDUSTRIALE DEL SISTEMA CONTROLLATO ARCHITETTURA STRUMENTAZIONE COMUNICAZIONE RETI DI DI CONTROLLO MODALITÀ CONOSCENZA APPROFONDITA DEL FUNZIONAMENTO E DEL COMPORTAMENTO DEL SISTEMA DA CONTROLLARE FISICA - CHIMICA - MECCANICA ELETTROTECNICA - ELETTRONICA - INFORMATICA SCIENZE DI BASE DELL’INGEGNERIA FORMAZONE CULTURALE 18

Vincoli Prestazioni Costo PROGETTAZIONE DI UN SISTEMA COMPLESSO Competenze STRUMENTAZIONE MODALITÀ DI CONTROLLO TECNOLOGIE: Controllo manuale Controllo automatico Meccanica Vincoli Applicato a: Chimica Controllori locali Elettrotecnica Coordinamento Prestazioni Supervisione Costo Elettronica Gestione Informatica Esercizio COMPETENZE PER LA REALIZZ. DI UN SISTEMA DI CONTROLLO 19

(per la realizzazione del Specifiche Funzionali PROGETTAZIONE DI UN SISTEMA COMPLESSO Esperti (per la realizzazione del sistema controllato) Utente finale Analisi dei Requisiti Funzionali Standardizzazione Documentazione Progettazione delle Specifiche Funzionali PROGETTAZIONE DI UN SISTEMA DI PRODUZIONE 20

(IEEE STANDARD GLOSSARY OF SOFTWARE ENGINEERING TEMINOLOGY) PROGETTAZIONE DI UN SISTEMA COMPLESSO REQUISITI (IEEE STANDARD GLOSSARY OF SOFTWARE ENGINEERING TEMINOLOGY) CONDIZIONI O CAPACITÀ DI CUI L’UTENTE HA BISOGNO per risolvere un problema o raggiungere un obiettivo CONDIZIONI O CAPACITÀ CHE DEVONO ESSERE RAGGIUNTE O POSSEDUTE DA UN SISTEMA o da un suo componente per soddisfare un contratto, uno standard, una specifica o quanto prescritto da ogni altro tipo di documento imposto formalmente DOCUMENTAZIONE di tali condizioni o capacità COSA SONO I REQUISITI 21

PROGETTAZIONE DI UN SISTEMA COMPLESSO DEFINIZIONE DELLE PRESTAZIONI RICHIESTE DALL’UTENTE FINALE TRACCIABILITÀ E STORIA DEI CAMBIAMENTI DEFINIZIONE DELLE RISORSE NECESSARIE PER LA REALIZZAZIONE DEL PROGETTO ELENCO DELLE ATTIVITÀ CHE IL SISTEMA DEVE SVOLGERE CONOSCENZE DI BASE PER LA PROGETTAZIONE E PER LA OTTIMIZZAZIONE DEL PROGETTO APPROCCIO LOGICO ED ECONOMICO AI CAMBIAMENTI SUDDIVISIONE DEL LAVORO DI PROGETTAZIONE IN GRUPPI ORGANIZZAZIONE DELLE PROVE E DELLE METRICHE DI VALUTAZIONE PER IL RICONOSCIMENTO DEL LAVORO SVOLTO ANCHE DURANTE LO SVILUPPO DEL PROGETTO DOCUMENTAZIONE DEGLI ASPETTI SALIENTI DEL SISTEMA IN TERMINI NON STRETTAMENTE TECNICI IN MODO CHE POSSA ESSERE UTILIZZATO DALLE PERSONE COINVOLTE ORGANIZZAZIONE CONTRATTUALE EVIDENTE E CHIARA RUOLO DEI REQUISITI DEL SISTEMA DA PROGETTARE 22

REQUISITI UTENTE REQUISITI SISTEMA PROGETTAZIONE DI UN SISTEMA COMPLESSO I REQUISITI DI SISTEMA DESCRIVONO LE FUNZIONALITÀ NECESSARIE PER OTTENERE LE PRESTAZIONI DESIDERATE. I REQUISITI UTENTE DEFINISCONO LE PRESTAZIONI CHE L’UTENTE FINALE DESIDERA DAL SISTEMA. REQUISITI UTENTE REQUISITI SISTEMA Definiscono ciò che l’utente finale desidera ottenere Definiscono le attività del sistema Documentati dall’utente finale Definiti dal progettista Descrizione del sistema Descrizione “ ad oggetti” Organizzati per obiettivi Organizzati in forma gerarchica Definiti nel linguaggio utilizzato dall’utente finale Definiti nel linguaggio usato dai progettisti REQUISITI UTENTE E REQUISITI SISTEMA 23

Attività Documentazione PROGETTAZIONE DI UN SISTEMA COMPLESSO LA SPECIFICA DEI REQUISITI DI SISTEMA È L’ULTIMA FASE DI UNA SERIE DI ATTIVITÀ, AL TERMINE DI CIASCUNA DELLE QUALI VIENE PRODOTTO UN DOCUMENTO DIFFERENTE. Attività STUDIO FATTIBILITÀ ANALISI REQUISITI SVILUPPO PROTOTIPO STUDIO PROGETTO SPECIFICA REQUISITI RESOCONTO FATTIBILITÀ REQUISITI UTENTE RESOCONTO VALUTAZIONE PROGETTO ARCHITETTURA REQUISITI SISTEMA Documentazione DEFINIZIONE DEI REQUISITI 24

DURANTE IL FUNZIONAMENTO PROGETTAZIONE DI UN SISTEMA COMPLESSO REQUISITI FUNZIONALI REQUISITI NON FUNZIONALI COMPORTAMENTO DURANTE IL FUNZIONAMENTO PRESTAZIONI AFFIDABILITÀ ROBUSTEZZA ADATTATIVITÀ TOLLERANZA AI GUASTI SICUREZZA COSTO TESTABILITÀ MANUTENIBILITÀ RIUSABILITÀ DOCUMENTAZIONE LEGAME FRA LE VARIABILI: DI INTERVENTO INTERNE CONTROLLATE DURANTE LA PROGETTAZIONE REQUISITI: POSSIBILE CLASSIFICAZIONE 25

PROGETTAZIONE DI UN SISTEMA COMPLESSO AFFIDABILITÀ (RELIABILITY): capacità di un’unità produttiva di compiere la funzione richiesta, in condizioni stabilite e per un determinato intervallo di tempo. DISPONIBILITÀ (AVAILABILITY): capacità di un prodotto di essere in grado si eseguire la funzione richiesta nelle condizioni imposte ad un determinato istante oppure durante un determinato intervallo di tempo, supponendo che siano fornite le risorse esterne necessarie. MANUTENIBILITÀ (MAINTAINABILITY): probabilità che per una data unità produttiva, utilizzata in condizioni di impiego stabilite, possa essere svolta, durante un intervallo di tempo stabilito, una data azione di manutenzione attiva, attuata secondo condizioni stabilite, e con l’impiego delle procedure e dei mezzi prescritti. SICUREZZA (SAFETY): assenza di livelli intollerabili di rischio di danno. A queste proprietà si debbono in generale aggiungere altri fattori: Economici: costi di progetto, produzione, manutenzione; Sociali: impatto del sistema sul livello di vita del cittadino e sul mondo del lavoro; Ambientali: impatto ecologico dei prodotti: deve far parte dell’analisi dei rischi del prodotto; Politici FATTORI CONSIDERATI NELLA STESURA DEI REQUISITI 26 PROBLEMI EMERGENTI

PROPRIETÀ DEI REQUISITI PROGETTAZIONE DI UN SISTEMA COMPLESSO PROPRIETÀ DEI REQUISITI Globali (contemplanti l’intero sistema) Corretti (possibilità, rispondenza a norme) Completi (frasi e termini di senso compiuto) Chiari (non ambiguità) Consistenti (nessun conflitto tra requisiti) Modificabili (possibilità di aggiornamento) Verificabili (criteri oggettivi e metriche precise) Tracciabili (identificazione univoca) Fattibili (limiti temporali e di budget) Minimali (non ridondanza e necessità) PROPRIETÀ DEI REQUISITI 27 PROBLEMI EMERGENTI

Requisiti per la realizzazione di un sistema controllato PROGETTAZIONE DI UN SISTEMA COMPLESSO Requisiti per la realizzazione di un sistema controllato E’ fondamentale la conoscenza approfondita delle modalità di funzionamento del sistema da controllare. E’ richiesta la conoscenza delle modalità di controllo applicate ai vari livelli del sistema controllato. REALIZZAZIONE DI UN SISTEMA DI AUTOMAZIONE 28

PROGETTAZIONE DI UN SISTEMA COMPLESSO Applicazioni senza teoria Teoria senza applicazioni Secondo il principio: “Una volta formulato il problema, definito il modello e soddisfatte le ipotesi, si dimostra che …” Secondo il principio: “purché funzioni e assicuri i margini di convenienza economica, tutto va bene” Applicazione della teoria a problemi significativi e teoria mirata alle applicazioni Secondo il principio: “Migliorare la qualità delle prestazioni mediante l’applicazione e l’estensione della teoria a problemi concreti” APPROCCI ALLA APPLICAZIONE DELLE METODOLOGIE 29

PROGETTAZIONE DI UN SISTEMA COMPLESSO È molto diffusa l’opinione che basandosi solo sull’empirismo e sull’esperienza si possa rendere funzionante un sistema controllato una volta installata la strumentazione Ciò continua a far credere che una preparazione metodologica adeguata non risulti di concreta utilità, anche perché gli impianti sono stati realizzati in modo che possano funzionare anche senza un sistema di automazione adeguato. Ciò porta a non tenere conto dei benefici che potrebbero essere ottenuti applicando modalità di controllo adeguate, ossia prendendo in considerazione congiuntamente la realizzazione e il controllo. APPROCCIO ALLE METODOLOGIE 30

SISTEMA DA CONTROLLARE PROGETTAZIONE DI UN SISTEMA COMPLESSO Influenza delle INTERAZIONI SISTEMA DA CONTROLLARE MODALITÀ DI CONTROLLO PRESTAZIONI Si accettano quelle che si riescono ad ottenere. Empiriche Dimensionato senza tenere conto della modalità di controllo. Sistematiche Convenzionali Vengono imposte tramite le modalità di controllo in modo: Dimensionato in funzione della modalità di controllo. Emergenti Rigido Innovative Flessibile INFLUENZA DELLE INTERAZIONI 31

REALIZZAZIONE Analisi del sistema da controllare PROGETTAZIONE DI UN SISTEMA COMPLESSO REALIZZAZIONE Analisi del sistema da controllare Progettazione del sistema da controllare Realizzazione di impianti e apparati Accettazione in fabbrica dei componenti Accettazione nel sistema di produzione Progettazione del sistema di controllo Realizzazione del sistema di controllo Collaudo delle prestazioni del sistema controllato Gestione delle modifiche ORGANIZZAZIONE DELLA REALIZZAZIONE 32

REALIZZAZIONE OBIETTIVI PROVE DI ACCETTAZIONE SPECIFICHE PROVE DI PROGETTAZIONE DI UN SISTEMA COMPLESSO OBIETTIVI PROVE DI ACCETTAZIONE VINCOLI SULLA STRUTTURA SULLE APPARECCHIATURE SPECIFICHE PROVE DI FUNZIONALITÀ ARCHITETTURA FUNZIONALE PROGETTAZIONE PROVE PARZIALI SUI COMPONENTI ARCHITETTURA DI IMPIANTO REALIZZAZIONE PROBLEMI EMERGENTI EARLY STATE MANAGEMENT 33

Suddivisione delle attività PROGETTAZIONE DI UN SISTEMA COMPLESSO Suddivisione delle attività Attività principali Trasferimento delle informazioni Revisioni Principali obiettivi Definizione delle Esigenze: Finalità e prestazioni richieste dal committente Architettura del sistema controllato Progettazione delle singole parti Assemblaggio e prove di validazione Modalità di utilizzazione Messa in esercizio Documentazione 34 ORGANIZZAZIONE DELLA PROGETTAZIONE

DOCUMENTAZIONE Definizione delle finalità richieste dal committente PROGETTAZIONE DI UN SISTEMA COMPLESSO Definizione delle finalità richieste dal committente Definizione delle prestazioni desiderate Progettazione dell’architettura di sistema Progettazione delle singole parti DOCUMENTAZIONE Realizzazione delle singole parti Assemblaggio Prove di validazione Messa in esercizio Modalità di utilizzazione PIANIFICAZIONE DELLA GESTIONE DEL SOFTWARE 35

PROGETTAZIONE DELLA ARCHITETTURA PROGETTAZIONE DETTAGLIATA PROGETTAZIONE DI UN SISTEMA COMPLESSO DEFINIZIONE ESIGENZE UTENTE DEFINIZIONE ESIGENZE SOFTWARE PROGETTAZIONE DELLA ARCHITETTURA PROGETTAZIONE DETTAGLIATA PRODUZIONE DEL CODICE TRASFERIMENTO FUNZIONAMENTO MANTENIMENTO PIANIFICAZIONE DELLA GESTIONE DEL SOFTWARE 36

PROGETTAZIONE DI UN SISTEMA COMPLESSO DEFINIZIONE ESIGENZE UTENTE VERIFICA E VALIDAZIONE PROVE PER L’ACCETTAZIONE DEFINIZIONE ESIGENZE SOFTWARE VERIFICA E VALIDAZIONE PROVE SUL SISTEMA COMPLETO VERIFICA VALIDAZIONE PROVE SULLA INTEGRAZIONE DEI MODULI PROGETTAZIONE DELLA ARCHITETTURA PROGETTAZIONE DETTAGLIATA PROVE SU OGNI MODULO PRODUZIONE DEL CODICE PIANIFICAZIONE DELLA GESTIONE DEL SOFTWARE 37

Oggetto fisico che imita il sistema PROGETTAZIONE DI UN SISTEMA COMPLESSO Definizione: Il Modello di un sistema è un oggetto, diverso dal sistema, sul quale può essere operata una verifica (esperimento) al fine di rispondere a domande su quel sistema. Tipi di modello: MODELLO MENTALE - Es: “onestà” MODELLO VERBALE MODELLO FISICO Espresso a parole Oggetto fisico che imita il sistema MODELLO FORMALE Rappresentazione formale di idee o conoscenze relative ad un sistema, finalizzata alla comprensione, interpretazione, previsione e controllo del sistema (prototipo virtuale). CONCETTO DI MODELLO 38

Un modello può essere di tipo PROGETTAZIONE DI UN SISTEMA COMPLESSO Un modello costituisce una rappresentazione astratta di un sistema (fisico o concettuale). E’ utilizzato dal progettista come uno strumento per effettuare un prima verifica della validità delle proprie attività. Un modello può essere di tipo Funzionale Comportamentale Strutturale Affinché un modello possa essere valido è opportuno che risulti: Eseguibile con un programma di calcolo Facilmente giustificabile Facilmente comprensibile Affidabile PROCEDURA DI MODELLAZIONE 39

MODELLO CONCETTUALE Modello funzionale Modello comportamentale Modello PROGETTAZIONE DI UN SISTEMA COMPLESSO Modello funzionale MODELLO CONCETTUALE Cosa fa il sistema in esame DESCRIZIONE PUNTUALE DELLE ATTIVITÀ E DELLE PRESTAZIONI Modello comportamentale Come può essere riutilizzato DESCRIZIONE DEL COMPORTAMENTO, DEL CONTROLLO E DELLA TEMPORIZZAZIONE MODELLO FISICO Modello strutturale Come è stato realizzato DESCRIZIONE IN OGGETTI, MODULI E LINEE DI COMUNICAZIONE MODELLO DI UN SISTEMA 40

MODELLO DEL SISTEMA COMPLESSO PROGETTAZIONE DI UN SISTEMA COMPLESSO MODELLO DEL SISTEMA COMPLESSO MODELLO DELLA FUNZIONALITÀ MODELLO DEL COMPORTAMENTO MODELLO DELLA STRUTTURA DIAGRAMMA DEI CASI D’USO DIAGRAMMA DELLE COLLABORAZIONI DIAGRAMMA DEI COMPONENTI DIAGRAMMA DELLE CLASSI DIAGRAMMA DEGLI OGGETTI DIAGRAMMA DELLE DISTRIBUZIONI DIAGRAMMA DELLE ATTIVITÀ DIAGRAMMA DELLE SEQUENZE DIAGRAMMA DEGLI STATI MODELLO DI UN SISTEMA 41

Motivazioni Definizione: PROGETTAZIONE DI UN SISTEMA COMPLESSO Definizione: La simulazione è un esperimento operato su un modello. Motivazioni - Esperimenti sul sistema reale costosi o pericolosi; - Sistema reale (ancora) non disponibile; Grandezze fisiche non compatibili con quelle dello sperimentatore; (ad. es. durata dell’esperimento) - Variabili inaccessibili - Facile manipolazione dei modelli - Soppressione dei disturbi SIGNIFICATO DI SIMULAZIONE 42

PROGETTAZIONE DI UN SISTEMA COMPLESSO Oltre a fornire il modello di architettura completa per il sistema in esame, la metodologia rappresenta anche un importante paradigma progettuale, che consente di: Ridurre i costi di progettazione, attraverso modelli indipendenti dal sistema operativo e dall’hardware Ridurre i costi dell’hardware e delle tecnologie utilizzati nei sistemi di controllo Omogeneizzare le conoscenze dei vari tecnici coinvolti nella progettazione e ridurre i costi di addestramento del personale Uniformare le rappresentazioni di tutti i componenti del sistema di controllo Definire le interfacce standard per la comunicazione tra i componenti del sistema RUOLO DELLA SIMULAZIONE 43

PERICOLI Modelli e Simulazione: “effetto Pigmalione” PROGETTAZIONE DI UN SISTEMA COMPLESSO Modelli e Simulazione: PERICOLI Innamorarsi del modello: dimenticare che il modello non appartiene al mondo reale. METODI DI IDENTIFICAZIONE DEI PARAMETRI DI UN MODELLO RICORSIVO CONROLLO NON LINEARE DISACCOPPIANTE DI UN MOTORE ASINCRONO “effetto Pigmalione” Forzare la realtà ad avere lo stesso comportamento del modello. SISTEMA DA CONTROLLARE SOVRADIMENSIONATO PER POTER APPLICARE UN REGOLATORE PI “effetto letto di Procuste” Dimenticare il livello di accuratezza del modello: semplificare troppo le premesse. MODELLI E SIMULAZIONE: PERICOLI 44

 Formulazione Esperti di dominio Validazione Modello Consistenza PROGETTAZIONE DI UN SISTEMA COMPLESSO Esperti di dominio Validazione Formulazione Verifica Informale Modello Verifica Consistenza Verifica Formale Consistenza Implementazione Altro modello  Consistenza RUOLO DEL MODELLO NELLA PROGETTAZIONE 45

Strumento di supporto per la verifica di un modello PROGETTAZIONE DI UN SISTEMA COMPLESSO Strumento di supporto per la verifica di un modello Esperto di dominio Linguaggio di modellazione dei requisiti Prove Modello dei requisiti Addetto alla verifica Vincoli formali VERIFICA DI UN MODELLO 46

Limitato numero simboli grafici per sviluppare i vari modelli PROGETTAZIONE DI UN SISTEMA COMPLESSO Il linguaggio UML Strumento indiscusso per rappresentare In forma grafica Programmi software; Realizzazioni hardware; Sistemi organizzativi Gli aspetti di maggiore interesse mediante modelli standard. Struttura del linguaggio UML Differenti modelli grafici per rappresentare gli aspetti significativi collegati alla struttura e alle condizioni operative dei vari modelli Limitato numero simboli grafici per sviluppare i vari modelli UML Possibilità espandere la capacità di rappresentazione dei singoli modelli Vari software di supporto ad UML disponibili in rete IL LINGUAGGIO UML 47

Il linguaggio UML Non proprietario PROGETTAZIONE DI UN SISTEMA COMPLESSO Il linguaggio UML Non proprietario Impiega pochi simboli standardizzati Per forward & reverse engineering Orientato agli oggetti Permette di descrivere dettagliatamente un sistema per quanto riguarda: La struttura La modalità di funzionamento I collegamenti con l’esterno IL LINGUAGGIO UML 48

Perché orientato agli oggetti PROGETTAZIONE DI UN SISTEMA COMPLESSO Perché orientato agli oggetti È in grado di dominare la complessità e l’eterogeneità dei sistemi complessi. Massimizza: La portabilità La personalizzabilità La modularità Un oggetto UML mostra: L’utilizzazione Il funzionamento La realizzazione La manutenzione La qualità L’ubicazione MOTIVAZIONE DELLA RAPPRESENTAZIONE AD OGGETTI 49

Modelli utilizzati per la progettazione PROGETTAZIONE DI UN SISTEMA COMPLESSO Modelli utilizzati per la progettazione Modelli secondo blocchi funzionali Modello del sistema, suddiviso in blocchi funzionali Comunicanti. Modelli di applicazione Modello di un determinato sistema con una determinata funzionalità. Modelli di utilizzazione Funzionalità e prestazioni offerte all’ utilizzatore. Modelli di una risorsa Modello di un componente/ apparecchiatura/ impianto. Modelli di un dispositivo Modello di elemento singolo con funzionalità propria. MODELLI PER LA PROGETTAZIONE 50

Le soluzioni offerte dall’UML: PROGETTAZIONE DI UN SISTEMA COMPLESSO Le soluzioni offerte dall’UML: Comunicazione con l’esterno - Diagramma dei casi d’uso - Diagramma delle collaborazioni Struttura del sistema - Diagramma delle classi - Diagramma degli oggetti - Diagramma dei componenti - Diagramma delle distribuzioni Funzionamento - Diagramma degli stati - Diagramma delle attività - Diagramma delle sequenze DIAGRAMMI UML 51

Uso dei diagrammi UML PROGETTAZIONE DI UN SISTEMA COMPLESSO Definizione delle attività: 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 distribuzione. Presentazione dei risultati: terminata la raccolta delle informazioni vengono presentati i risultati delle 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 52

PROGETTAZIONE DI UN SISTEMA COMPLESSO IL LINGUAGGIO UML Analisi delle transizioni di stato: durante la creazione dei modelli vengono analizzate le eventuali transizioni di stato di ogni 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 ed 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 53

15 progettazione di un sistema complesso IL LINGUAGGIO UML Realizzazione del codice: con il diagramma delle classi, il diagramma degli oggetti, il diagramma delle attività ed 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 15 USO DEI DIAGRAMMI 54

Diagramma delle attività Barra di sincronizzazione PROGETTAZIONE DI UN SISTEMA COMPLESSO Diagramma delle attività Attività Utile: Per modellare e sincronizzare le attività svolte dal sistema. Per indicare le variabili di attivazione. Fork Attività 1 Barra di sincronizzazione Percorso Decisionale ? No Si Attività 2 Attività 3 Transizione Utilizza barre di sincronizzazione e blocchi logico-decisionali per visualizzare il flusso delle informazioni. Percorsi Concorrenti Attività 4 Attività 5 Join Usa i fork/join per i processi paralleli: un join si supera solo quando tutti i processi che vi confluiscono sono pronti. Le attività sono ordinate verticalmente in base all’og-getto che ha la responsabi-lità di portarle avanti (linee di divisione = swimlines). DIAGRAMMA DELLE ATTIVITÀ 55

Diagramma delle classi PROGETTAZIONE DI UN SISTEMA COMPLESSO Diagramma delle classi CLASSE ATTRIBUTI ASSOCIAZIONI Oggetto 1 Oggetto 2 Possibili associazioni 0…٭ 0…1 1 …٭ 0…y x…1 Y …٭ Descrizione orientata agli oggetti del sistema. Ogni classe è caratterizzata da nome - attributi - operazioni Per ogni attributo viene indicato il livello di accesso pubblico - protetto - privato Le classi sono collegate tra loro tramite le “associazioni” e la “molteplicità delle associazioni”. Non viene fatto riferimento agli eventi di sincronizzazione ma solo alla struttura. ASSOCIAZIONE AGGREGAZIONE COMPOSIZIONE REALIZZAZIONE EREDITARIETÀ Ogni classe è inoltre corredata da una specifica di funzionalità, di prestazioni, di funzionamento normale (schema di base), di funzionamento anomalo (estensioni). DIAGRAMMA DELLE CLASSI 56

Diagramma delle distribuzioni PROGETTAZIONE DI UN SISTEMA COMPLESSO Diagramma delle distribuzioni Mostra la macro-architettura di più sistemi collegati. L’elemento chiave, una risorsa fisica, è il nodo rappresentato da un cubo. Il cubo può avere capacità di elaborazione o fungere solo da collegamento con una interfaccia. I nodi sono in genere collegati da associazioni rappresentanti un link fisico. Connessione tra nodi NOME Nodo DIAGRAMMA DELLE DISTRIBUZIONI 57

Diagramma dei casi d’uso PROGETTAZIONE DI UN SISTEMA COMPLESSO Diagramma dei casi d’uso ATTORE CASO D’USO Interazioni tra sistema ed entità esterne (cioè gli utilizzatori, detti attori). Quindi nello schema si ha: l’utente/dispositivo x che può utilizzare il sistema nel modo (caso d’uso) y. Si utilizzano associazioni o generalizzazioni. DIAGRAMMA DEI CASI D’USO 58

VARIABILI CARATTERIZZANTI LO STATO Evento / condizione / azione PROGETTAZIONE DI UN SISTEMA COMPLESSO Diagramma degli stati Stato iniziale NOME 2 Mette in rilievo la sequenza di attivazione dei vari oggetti, nonché lo stato iniziale e finale. Mostra le condizioni che implicano un passaggio di stato. È in grado di mostrare attività parallele. Si basa sul concetto di evento. VARIABILI CARATTERIZZANTI LO STATO ATTIVITÀ Evento / condizione / azione NOME 2 VARIABILI CARATTERIZZANTI LO STATO ATTIVITÀ Stato finale DIAGRAMMA DEGLI STATI 59

Diagramma delle sequenze PROGETTAZIONE DI UN SISTEMA COMPLESSO Diagramma delle sequenze Sequenza temporale delle interazioni che si stabiliscono tra i vari oggetti componenti il sistema. L’asse verticale rappresenta il tempo. L’asse orizzontale gli oggetti e gli attori. Messaggio Oggetto Possono essere quindi rappresentate anche le durate di ogni singola iterazione. Attore Messaggio di chiamata Ad un altro oggetto Messaggio di chiamata Allo stesso oggetto Attività dell’oggetto Messaggio di risposta Ad un altro oggetto Messaggio di risposta Allo stesso oggetto Messaggio asincrono Messaggio ricorsivo DIAGRAMMA DELLE SEQUENZE 60

Diagramma delle collaborazioni PROGETTAZIONE DI UN SISTEMA COMPLESSO Diagramma delle collaborazioni Oggetto AZIONE 1 Nome 1 Nome 3 AZIONE 3 Messaggio AZIONE 2 Attore Nome 2 Mostra il modo in cui vari oggetti ed attori comunicano tra di loro. Gli oggetti sono rappresentati da un quadrato. Non rappresenta la cronologia di tale comunicazione. Sul link va indicato il messaggio scambiato. DIAGRAMMA DELLE COLLABORAZIONI 61

Diagramma degli oggetti PROGETTAZIONE DI UN SISTEMA COMPLESSO Diagramma degli oggetti CLASSE ATTRIBUTI OPERAZIONI OGGETTO 1 OGGETTO 2 ATTRIBUTO DELLA ASSOCIAZIONE OPERAZZIONI OGGETTO 3 Si tratta di diagrammi sostanzialmente analoghi ai diagrammi delle classi (si ricavano infatti da essi), con la differenza che rappresentano le istanze vere e proprie di tali classi cioè oggetti reali costituiti come istanza di una classe. DOCUMENTAZIONE DEL SOFTWARE DI CONTROLLO 62

Diagramma dei componenti PROGETTAZIONE DI UN SISTEMA COMPLESSO Diagramma dei componenti COMPONENTE [NOME PACKAGE] NOME COMPONENTE 1 COMPONENTE 3 COMPONENTE 2 RELAZIONE DI DIPENDENZA Fornisce una visione temporale e strutturale del sistema funzionante. Mostra in particolare i collegamenti tra componenti. È lecito raggruppare più componenti in un unico insieme (apparato). DIAGRAMMA DEI COMPONENTI 63

Lo standard di progettazione ESA-PSS05 PROGETTAZIONE DI UN SISTEMA COMPLESSO Lo standard di progettazione ESA-PSS05 serie di norme standard di sviluppo e di ingegneria del software originariamente sviluppato per i soli prodotti software dell’agenzia spaziale europea (ESA) oggi largamente utilizzato anche dalle compagnie private permette una gestione ed un controllo completo e funzionale di tutte le fasi di sviluppo regolamenta il progettazione di tutti i componenti e di tutte le interfacce del sistema software LO STANDARD DI PROGETTAZIONE ESA-PSS05 64

La normativa ESA si articola nella seguenti fasi: PROGETTAZIONE DI UN SISTEMA COMPLESSO La normativa ESA si articola nella seguenti fasi: FASE 1: requirements capture process FASI 2 & 3: analysis & design FASI 4 & 5: realizzazione e prove per la validazione NORMATIVA ESA PER LA PROGETTAZIONE 65

FASE 1: REQUIREMENTS CAPTURE PROCESS PROGETTAZIONE DI UN SISTEMA COMPLESSO FASE 1: REQUIREMENTS CAPTURE PROCESS INFORMAZIONI SU STRUTTURA E FUNZIONAMENTO INFORMAZIONI SULL’ INTEGRAZIONE CON SISTEMI GIÀ ESISTENTI INFORMAZIONI SULLE PRESTAZIONI DESIDERATE INFORMAZIONI SULLA QUALITÀ DESIDERATA INFORMAZIONI SUI TEMPI DI CONSEGNA INFORMAZIONI SUI MOMENTI E SULLE MODALITÀ DI VERIFICA DIPENDENTI DAGLI ACCORDI CON IL CLIENTE INOLTRE, PER OGNI MODULO SI RISCONTRA: ALTA COESIONE BASSO ACCOPPIAMENTO INTERFACCIAMENTO ESPLICITO RISERVATEZZA DELLE INFORMAZIONI INDIVIDUAZIONE DEI REQUISITI 66

FASI 2 & 3: ANALYSIS & DESIGN PROGETTAZIONE DI UN SISTEMA COMPLESSO FASI 2 & 3: ANALYSIS & DESIGN DEFINIZIONE ATTIVITÀ (ACTIVITY DIAGRAM) ANALISI SISTEMA (CLASS DIAGRAM) CORRELAZIONE TRA SISTEMI (DISTRIBUTION DIAGRAM) COMPRENSIONE UTILIZZO (USE CASES DIAGRAM) ANALISI TRANSIZIONI DI STATO (STATE CHART DIAGRAM) INTERAZIONE TRA OGGETTI (SEQUENCE&COLLABORATION DIAGRAM) INTEGRAZIONE CON SISTEMI PRE-ESISTENTI (DISTRIBUTION DIAGRAM) DEFINIZIONE OGGETTI (OBJECTS DIAGRAM) DEFINIZIONE COMPONENTI (COMPONENT DIAGRAM) IN OGNI FASE NON BISOGNA MAI PERDERE IL CONTATTO CON IL CLIENTE!  RELAZIONI & VERIFICHE ANALISI E PROGETTAZIONE 67

FASI 4 & 5: REALIZAZIONE E PROVE PER LA VALIDAZIONE PROGETTAZIONE DI UN SISTEMA COMPLESSO FASI 4 & 5: REALIZAZIONE E PROVE PER LA VALIDAZIONE QUESTE FASI COMPRENDONO: LA REALIZZAZIONE DEI SINGOLI SISTEMI LE PROVE DEI SINGOLI SISTEMI REALIZZATI L’INTEGRAZIONE TRA DI LORO E CON SISTEMI ESISTENTI LE PROVE DI INTEGRAZIONE, PER VERIFICARE IL FUNZIONAMENTO DEL SISTEMA COMPLESSIVO SONO PARTICOLARMENTE IMPORTANTI IN QUANTO DANNO GRANDI INFORMAZIONI AL CLIENTE SULLA QUALITÀ E SULLA QUANTITÀ DEL LAVORO SVOLTO. CONSENTONO DI . . . TIRARE LE SOMME! REALIZZAZIONE E PROVE DI VALIDAZIONE 68

PROGETTAZIONE DI UN SISTEMA COMPLESSO LO STANDARD ESA PSS-05 SI INTERFACCIA TOTALMENTE CON IL CICLO DI SVILUPPO UML UML PUÒ QUINDI ESSERE EFFICACEMENTE UTILIZZATO NELLA PROGETTAZIONE ESA PSS-05 UNIFIED MODELLING LANGUAGE FASE 1: REQUIREMENTS CAPTURE PROCESS USER REQUIREMENTS DEFINITION SOFTWARE REQUIREMENTS DEFINITION FASE 2: ANALYSIS ARCHITECTURAL DESIGN PHASE FASE 3: DESIGN DETAILED DESIGN & PRODUCTION FASE 3: DESIGN FASI 4 & 5: REALIZZAZIONE PROVE DI VALIDAZIONE TRASFER & TESTS OPERATION & MAINTENACE NORME ESA E UML 69

REALIZZAZIONE DELLE PARTI IN HARDWARE PROGETTAZIONE DI UN SISTEMA COMPLESSO INGEGNERIA DI SISTEAMA BASE DELLA CONOSCENZA DEFINIZIONE DELLE FINALITÀ E DELLE PRESTAZIONI MESSA IN ESERCIZIO ACCETTAZIONE MODELLO FUNZIONALE DELLA NUOVA REALIZZAZIONE PROVE DI FUNZIONALITÀ INTEGRAZIONE DELLA NUOVA REALIZZAZIONE ARCHITETTURA DELLA NUOVA REALIZZAZIONE PROVE DI FUNZIONALITÀ SOFTWARE INTEGRAZIONE IN SOTTOSISTEMI REALTÀ VIRTUALE DELLA NUOVA REALIZZAZIONE PROVE DI FUNZIONALITÀ REALIZZAZIONE DELLE PARTI IN SOFTWARE INTEGRAZIONE DELLE PARTI HARDWARE E SOFTWARE REALIZZAZIONE DELLE PARTI IN HARDWARE PROCEDURA SISTEMATICA DI PROGETTAZIONE 70

BASE DELLA CONOSCENZA UML UML UML UML UML UML UML UML UML PROGETTAZIONE DI UN SISTEMA COMPLESSO UML DIAGRAMMA DELLE ATTIVITÀ UML DIAGRAMMA DEI CASI D’USO UML DIAGRAMMA DELLE COLLABORAZIONI UML DIAGRAMMA DEGLI OGGETTI DEFINIZIONE DELLE FINALITÀ E DELLE PRESTAZIONI MODELLO FUNZIONALE DELLA NUOVA REALIZZAZIONE ARCHITETTURA DELLA NUOVA REALIZZAZIONE REALTÀ VIRTUALE REALIZZAZIONE DELLE PARTI IN SOFTWARE REALIZZAZIONE DELLE PARTI IN HARDWARE INTEGRAZIONE DELLE PARTI HARDWARE E SOFTWARE PROVE DI FUNZIONALITÀ INTEGRAZIONE IN SOTTOSISTEMI INTEGRAZIONE ACCETTAZIONE MESSA IN ESERCIZIO BASE DELLA CONOSCENZA UML DIAGRAMMA DEGLI STATI UML DIAGRAMMA DELLE CLASSI UML DIAGRAMMA DELLE DISTRIBUZIONI UML DIAGRAMMA DEI COMPONENTI UML DIAGRAMMA DELLE SEQUENZE ESA PSS-05 DOCUMENTAZIONE DEL SOFTWARE DOCUMENTAZIONE DELLA PROGETTAZIONE 71

UNA APPLICAZIONE VISTA DELL’UTENTE MODELLAZIONE UML PROGETTAZIONE DI UN SISTEMA COMPLESSO LIVELLO CONCETTUALE LIVELLO FISICO REQUISITI FUNZIONALI REALIZZAZIONE PROGRAMMI PER UTENTE FINALE IL FUNZIONAMENTO CASO D’USO UNA APPLICAZIONE VISTA DELL’UTENTE FUNZIONALITÀ LA GESTIONE ATTIVITÀ DA SVOLGERE UTILIZZAZIONE INTEGRATORE DI SISTEMA INGEGNERIA DI SISTEMA COMPORTAMENTO ISTALLAZIONE PRESTAZIONI COMUNICAZIONE PUNTI DI VISTA 72

COMANDO POSIZIONE SLITTA COMANDO MOVIMENTO TRAPANO PROGETTAZIONE DI UN SISTEMA COMPLESSO APPROCCIO OBJECT ORIENTED PANNELLO DI CONTROLLO COMANDO POSIZIONE SLITTA COMANDO MOVIMENTO TRAPANO DISPOSITIVO DI CONTROLLO TRAPANO RETE DI COMUNICAZIONE TRA I DISPOSITIVI DI CONTROLLO DISPOSITIVO DI CONTROLLO SLITTA ESEMPIO DI APPARATO 73

PROGETTAZIONE DI UN SISTEMA COMPLESSO APPROCCIO OBJECT ORIENTED LA LAVORAZIONE PUÒ INIZIARE IL PEZZO È CARICATO SULLA SLITTA IL PEZZO È PORTATO SOTTO IL TRAPANO IL TRAPANO PUÒ INIZIARE LA LAVORAZIONE IL TRAPANO EFFETTUA LA LAVORAZIONE IL TRAPANO HA CONCLUSO LA LAVORAZIONE IL TRAPANO È ALLONTANATO DAL PEZZO IL PEZZO È SCARICATO DALLA SLITTA LA LAVORAZIONE È CONCLUSA FASI DELLA LAVORAZIONE 74

CICLO DI LAVORO PROGETTAZIONE DI UN SISTEMA COMPLESSO APPROCCIO OBJECT ORIENTED CICLO DI LAVORO INIZIO CICLO MOVIMENTO PEZZO IL PEZZO DA LAVORARE VIENE POSIZIONATO SULLA SLITTA MOVIMENTO SLITTA LA SLITTA VIENE POSIZIONATA SOTTO IL TRAPANO MOVIMENTO TRAPANO VIENE ABBASSATO IL TRAPANO LAVORAZIONE VIENE AVVIATA LA LAVORAZIONE MOVIMENTO TRAPANO TERMINATA LA LAVORAZIONE, IL TRAPANO VIENE SOLLEVATO MOVIMENTO SLITTA ILTRAPANO VIENE FERMATO VIENE MOVIMENTATA LA SLITTA PER SCARICARE IL PEZZO MOVIMENTO PEZZO FINE CICLO ESEMPIO DI APPARATO 75

COMANDO POSIZIONE SLITTA COMANDO MOVIMENTO TRAPANO PROGETTAZIONE DI UN SISTEMA COMPLESSO APPROCCIO OBJECT ORIENTED PANNELLO DI CONTROLLO COMANDO POSIZIONE SLITTA COMANDO MOVIMENTO TRAPANO DISPOSITIVO DI CONTROLLO TRAPANO RETE DI COMUNICAZIONE TRA I DISPOSITIVI DI CONTROLLO ALTO SENSORI COMUNICAZIONE DATI BASSO MOVIMENTO TRAPANO MOVIMENTO PEZZO CARICA PRONTO ATTESA SENSORI DISPOSITIVO DI CONTROLLO SLITTA COMUNICAZIONE DATI ESEMPIO DI APPARATO 76

UNITA’ DI FORATURA AUTOMATICA PROGETTAZIONE DI UN SISTEMA COMPLESSO ESEMPIO MODELLAZIONE UML UNITA’ DI FORATURA AUTOMATICA LAVORAZIONE NORMALE FUNZIONAMENTO OPERATORE/ IMPIANTO CONTROLLO TRAPANO SLITTA <<INCLUDE>> PROGETTISTA SETUP <<INCLUDE>> OPERATORE ARRESTA SISTEMA RIAVVIA GESTIONE ALLARMI MANUTENZIONE DIAGRAMMA DEI CASI D’USO 77

PROGETTAZIONE DI UN SISTEMA COMPLESSO ESEMPIO MODELLAZIONE UML PROGETTAZIONE DI UN SISTEMA COMPLESSO UNITÀ DI FORATURA + ESEGUI LAVORAZIONE () È COMPOSTA DA È COMPOSTA DA È COMPOSTA DA TRAPANO - POSIZIONE - OPERATIVITÀ + TRASLA () + RUOTA () COLLABORA CON COLLABORA CON SLITTA - POSIZIONE - OPERATIVITÀ + TRASLA () + RUOTA () CONTROLLORE - ATTESA - CONTROLLO + INVIA SEGNALE () + RICEVE SEGNALE () DIAGRAMMA DELLE CLASSI 78

PROGETTAZIONE DI UN SISTEMA COMPLESSO ESEMPIO MODELLAZIONE UML DIAGRAMMA DELLE CLASSI 79

PROGETTAZIONE DI UN SISTEMA COMPLESSO ESEMPIO MODELLAZIONE UML PROGETTAZIONE DI UN SISTEMA COMPLESSO CONTROLLO TRAPANO CONTROLLO SLITTA UNITÀ DI FORATURA TRAPANO SLITTA DIAGRAMMA DEGLI OGGETTI 80

7: INIZIO CICLO DI LAVORAZIONE ? PROGETTAZIONE DI UN SISTEMA COMPLESSO OPERATORE CONTROLLO SLITTA SLITTA CONTROLLO TRAPANO TRAPANO 1: INIZIA 2: CARICA PEZZO 3: CARICATO 4: A SINISTRA 5: PRONTO 6: PEZZO IN POSIZIONE 7: INIZIO CICLO DI LAVORAZIONE ? 8: AVVIARE TRAPANO 9: ABBASSA 10: LAVORAZIONE DIAGRAMMA DELLE SEQUENZE 81

PROGETTAZIONE DI UN SISTEMA COMPLESSO ESEMPIO MODELLAZIONE UML PROGETTAZIONE DI UN SISTEMA COMPLESSO APPROCCIO OBJECT ORIENTED OPERATORE CONTROLLO SLITTA SLITTA CONTROLLO TRAPANO TRAPANO 11: SOLLEVA 12 : IN ALTO 13: FINE LAVORAZIONE 14: A DESTRA 15 : IN ATTESA 16 : SCARICA 17 : SCARICATO 18: FINITO DIAGRAMMA DELLE SEQUENZE 82

LAVORAZIONE SLITTA IN PRONTO APPROCCIO OBJECT ORIENTED PROGETTAZIONE DI UN SISTEMA COMPLESSO ESEMPIO MODELLAZIONE UML LAVORAZIONE INIZIO SLITTA IN ATTESA SCARICA SLITTA IN ATTESA CARICA FINE SLITTA IN PRONTO CICLO TRAPANO TRAPANO ALTO FERMO TRAPANO ALTO ROTAZIONE TRAPANO BASSO LAVORAZIONE DIAGRAMMA DI STATO 83

PROGETTAZIONE DI UN SISTEMA COMPLESSO APPROCCIO OBJECT ORIENTED PROGETTAZIONE DI UN SISTEMA COMPLESSO OPERATORE SLITTA TRAPANO INIZIO CICLO AZIONA COMANDO SLITTA CARICAMENTO PEZZO SLITTA A SINISTRA AZIONA COMANDO TRAPANO AVVIAMENTO TRAPANO TRAPANO IN BASSO LAVORAZIONE DIAGRAMMA DELLE ATTIVITÀ 84

PROGETTAZIONE DI UN SISTEMA COMPLESSO ESEMPIO MODELLAZIONE UML APPROCCIO OBJECT ORIENTED OPERATORE SLITTA TRAPANO TRAPANO IN ALTO TRAPANO FERMO SLITTA A DESTRA SCARICA IL PEZZO FINE CICLO DIAGRAMMA DELLE ATTIVITÀ 85

RETE DI COMUNICAZIONEDATI ESEMPIO MODELLAZIONE UML PROGETTAZIONE DI UN SISTEMA COMPLESSO NODO 1 NODO 2 CONTROLLO SLITTA RETE DI COMUNICAZIONEDATI CONTROLLO TRAPANO SLITTA TRAPANO DIAGRAMMA DI DISTRIBUZIONE 86

UML IN SINTESI PROGETTAZIONE DI UN SISTEMA COMPLESSO MODELLAZIONE UML UML IN SINTESI UML È COMPLESSO E VA ADATTATO ALLE ESIGENZE DEI PROGETTISTI E AL CONTESTO DEL PROGETTO PRENDENDO IN CONSIDERAZIONE I SEGUENTI FATTORI: SETTORE DI ATTIVITÀ TIPOLOGIA DI PROGETTO ESIGENZE DI CONFORMITÀ A NORME COMUNICAZIONE CON COMMITTENTI E FORNITORI COMPOSIZIONE E DISTRIBUZIONE DEL GRUPPO DI LAVORO UML IN SINTESI 87

UML IN SINTESI PROGETTAZIONE DI UN SISTEMA COMPLESSO MODELLAZIONE UML UML IN SINTESI UML NON SUGGERISCE NÉ PRESCRIVE UNA SEQUENZA DI REALIZZAZIONE DEI DIVERSI DIAGRAMMI UML OFFRE UN’AMPIA GAMMA DI POSSIBILI MODALITÀ DI UTILIZZO TRA LE QUALI I PROGETTISTI SONO LIBERI DI SCEGLIERE NON TUTTI I DIAGRAMMI SONO UGUALMENTE UTILI IN OGNI CIRCOSTANZA IN OGNI APPLICAZIONE BISOGNA INDIVIDUARE QUALI DIAGRAMMI SONO EFFETTIVAMENTE NECESSARI PER LA REALIZZAZIONE DEL MODELLO UML IN SINTESI 88

CONCLUSIONI PROGETTAZIONE DI UN SISTEMA COMPLESSO Le metodologie di progetto orientate agli oggetti sono state adottate con successo nell’automazione industriale per far fronte alle seguenti esigenze: ridurre i tempi che intercorrono tra la progettazione e la realizzazione di un sistema sviluppare architetture software ad oggetti, che offrono maggiori possibilità di integrazione tra sistemi eterogenei realizzare sistemi di produzione, impianti ed apparati con strutture modulari che permettono: una semplice configurazione del sistema una manutenzione più rapida ed economica la possibilità di riconfigurazione la possibilità di inserimento di nuove unità CONCLUSIONI 89

PROGETTAZIONE DI UN SISTEMA COMPLESSO L’esistenza degli standard IEC e ISA fornisce le linee guida per la progettazione di architetture software orientate agli oggetti. Progettare sistemi con struttura non conforme agli standard si rivela un approccio perdente, perchè porta alla realizzazione di soluzioni proprietarie senza possibilità di integrazione con altri sistemi e non riutilizzabili, quindi più costose. CONCLUSIONI 90

PROGETTAZIONE DI UN SISTEMA COMPLESSO “The tendency in evolution is toward greater and greater specialization. Man's society is an ecology that forces adaptation to it. Continued complexity makes it impossible for us to know anything outside our own personal field.” Philip K. Dick “Lingvo internacia de la venontaj generacioj estos sole kaj nepre nur lingvo arta.” Ludoviko Zamenhof “Below every tangled hierarchy lies an inviolate level.” Douglas Hofstadter “A discipline that does not lead to a compassionate practice may be said to have failed.” Robert Fripp CONCLUSIONI 91

E MORÌ INCENERITO DA UN MISSILE PROGETTAZIONE DI UN SISTEMA COMPLESSO QUANDO NOÈ COSTRUÌ L’ARCA, ANCORA NON PIOVEVA DICEVA L’UOMO CON LA CLAVA: “DEVO FARE LA GUERRA, NON HO TEMPO PER CONOSCERE LE NUOVE TECNOLOGIE” E MORÌ INCENERITO DA UN MISSILE CONCLUSIONI 92